Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 01:32 PM 9/5/10, Spencer Oliver wrote: On 03/09/2010 20:29, John Hartman (NoICE) wrote: The STM32 parts have Flash beginning at 0x800, and OpenOCD's stm32x.c places the Flash there regardless of the address used in the flash command in the cfg file. The chips have two pins that can be jumpered to specify what appears at address 0: Flash, RAM, or the boot loader. For embedded work, I think Flash will be the most common case. But if I link my program at zero, it is a pain to burn my program, because OpenOCD tells gdb there is only RAM at 0, with Flash at 800. (material deleted for brevity) Just use the virtual bank cmd, that's what it there for flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME flash bank vbank0 virtual 0x 0 0 0 $_TARGETNAME $_FLASHNAME This is EXACTLY what I need. No changes to OpenOCD (aside from my cfg file), and no need to modify the configuration of other tools. Thank you. Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On 03/09/2010 20:29, John Hartman (NoICE) wrote: The STM32 parts have Flash beginning at 0x800, and OpenOCD's stm32x.c places the Flash there regardless of the address used in the flash command in the cfg file. The chips have two pins that can be jumpered to specify what appears at address 0: Flash, RAM, or the boot loader. For embedded work, I think Flash will be the most common case. But if I link my program at zero, it is a pain to burn my program, because OpenOCD tells gdb there is only RAM at 0, with Flash at 800. One solution is to re-link my program to 800, and rely on aliasing of the vector table to 0. This works, but is a little annoying. I would like to propose the following changes to allow Flash at zero: 1) In the file flash/stm32x.c, function stm32x_probe, remove or comment out the explicit setting of bank-base: // Don't fill in the base: get it from the cfg file // bank-base = 0x0800; bank-size = (num_pages * page_size); (etc.) 2) In the stm32.cfg, change flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME to flash bank $_FLASHNAME.1 stm32x 0x 0 0 0 $_TARGETNAME flash bank $_FLASHNAME.2 stm32x 0x0800 0 0 0 $_TARGETNAME This claims that there are TWO Flash banks, one at 0 and one at 800. By having two banks, users can locate their code at either location, as they prefer, without needing to modify the cfg file. Note that this would break existing cfg files, moving the Flash from 800 to 0. This could be remedied by using a non-zero value for one of the other parameters (bus width etc) to mean new style, and only using the specified base address in that case. (Or more formally, one might add a new algorithm instead of stm32x that does this) What do people think? Just use the virtual bank cmd, that s what it there for flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME flash bank vbank0 virtual 0x 0 0 0 $_TARGETNAME $_FLASHNAME Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Fri, Sep 3, 2010 at 11:48 PM, John Hartman (NoICE) j...@noicedebugger.com wrote: At 03:30 PM 9/3/10, Øyvind Harboe wrote: But it does what you need? Yes. My hope was to move from possible to configure to easy to use. But it is certainly possible to use load with an offset. That's OK. I just want to establish that we know what the problem and solution was. Today there is a solution, but it can be a bit inaccessible. I think we should make OpenOCD as easy as use as possible, but no easier. Perhaps this is a thing that *should* be a bit hard? Perhaps embedded users *should* learn about the load offset for GDB? Perhaps we can market the gdb load feature somehow instead of changing how the system works? -- Ø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] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
Øyvind Harboe wrote: Perhaps this is a thing that *should* be a bit hard? Perhaps embedded users *should* learn about the load offset for GDB? Do you know if gdb always sends an offset in the (binary?) command to OpenOCD? If yes, I think gdb should be changed to make 'load' easier to use. Can OpenOCD return a (textual?) error message? If yes, then OpenOCD could return a very informative error in case someone tries to load to an address not backed by flash. But ideally this knowledge should be up in gdb too, so that gdb, or whatever tool is controlling it, can provide more information and faster response to the user. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Sat, Sep 4, 2010 at 2:57 PM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: Perhaps this is a thing that *should* be a bit hard? Perhaps embedded users *should* learn about the load offset for GDB? Do you know if gdb always sends an offset in the (binary?) command to OpenOCD? If yes, I think gdb should be changed to make 'load' easier to use. This is not a problem with gdb. When gdb is asked to load an image it simply writes all relevant sections in that image to their respective memory locations. If it has knowledge that the location to be written resides in flash, it uses the vFlash* commands, otherwise it uses regular memory writes. If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. Yes, you can fix the error by telling gdb to load the image with an offset. That won't change the fact that the image is not linked correctly and gdb can hardly be blamed for providing the possibility of a workaround. Nor is it an OpenOCD problem. We just provide the knowledge to gdb about the memory layout of the target and then receive the memory writes. We can't guess the user's intentions and try to remap the writes behind gdb's (and the user's) back. Can OpenOCD return a (textual?) error message? If yes, then OpenOCD could return a very informative error in case someone tries to load to an address not backed by flash. We can't really tell the (non-flash) loads from other memory writes and we don't want to see errors on every write to peripheral or sram addresses. Even if we could we wouldn't want to print an error, because there is no error. And what would the message look like? It seems you're trying to load an image to a memory location not commonly used for loading to. Maybe you're using a broken linker script. Do you want me to try to fix the script for you? That would be neat. Why not take it a step further? I notice you try to load an image that has been compiled for another architecture than the one you're working on. Do you want me to install the correct cross compiler and recompile it for you? Based on your recent usage pattern I've come to the conclusion that you're getting desperate to find that nasty bug you introduced two weeks ago, before your deadline tomorrow morning. It's really late, so why don't you go home and get some sleep and I'll fix the bug for you. It looks like you're writing a letter. Would you like help? Aaargh! Ok maybe not such a great idea. Ok I got a little carried away there, sorry :). But my point is: We shouldn't remove the incentive for users to fix their tools or read up on the docs by reducing the impact of their errors or making it easier to work around them. But ideally this knowledge should be up in gdb too, so that gdb, or whatever tool is controlling it, can provide more information and faster response to the user. OpenOCD already gives gdb full knowledge of the target's memory layout (at least what is and isn't flash). /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
Both OpenOCD and GDB work perfectly well with correct files (standard OpenOCD .cfgs, correctly linked .elf file) so I really don't see any problem you're trying to fix... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
Andreas Fritiofson wrote: When gdb is asked to load an image it simply writes all relevant sections in that image to their respective memory locations. If it has knowledge that the location to be written resides in flash, it uses the vFlash* commands, otherwise it uses regular memory writes. Thanks! Sorry I'm a bit of a gdb noob. I've never used it in-depth in spite of using it a little, over lots of years. If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. I disagree; gdb can certainly discover this and do something more useful (error message, whatever) than trying to send stuff to OpenOCD *even though* it can not work. Yes, you can fix the error by telling gdb to load the image with an offset. What happens then, exactly? Does gdb relocate all sections or does it just send a single offset parameter to OpenOCD? That won't change the fact that the image is not linked correctly Agreed. and gdb can hardly be blamed for providing the possibility of a workaround. If anything I'm blaming gdb for not being smarter about when to automatically add the workaround - or at the *very least* providing relevant and useful error messages. Nor is it an OpenOCD problem. .. We can't guess the user's intentions And we shouldn't. We can't really tell the (non-flash) loads from other memory writes and we don't want to see errors on every write to peripheral or sram addresses. Even if we could we wouldn't want to print an error, because there is no error. There is not enough information for OpenOCD to accurately determine if it is an error or not. Remember that is very different from there is no error. Even in gdb there may not be enough information, since the load command is so generic. It seems you're trying to load an image to a memory location not commonly used for loading to. Maybe you're using a broken linker script. A message similar to this would be a significant and real improvement if it could be generated with zero false positives. Do you want me to try to fix the script for you? Silly. At most, whoever is generating the error (gdb IMO) could at this point list known memory areas. That would be neat. Why not take it a step further? .. We shouldn't remove the incentive for users to fix their tools or read up on the docs by reducing the impact of their errors or making it easier to work around them. Let me make another point, which I think is partially parallell partially orthogonal: There should be adequate error messages for all error cases. All error cases must be detected without heuristics and without ambiguity. But ideally this knowledge should be up in gdb too, OpenOCD already gives gdb full knowledge of the target's memory layout (at least what is and isn't flash). Good stuff. The problem is all in gdb then. Freddie Chopin wrote: Both OpenOCD and GDB work perfectly well with correct files (standard OpenOCD .cfgs, correctly linked .elf file) so I really don't see any problem you're trying to fix... Usability. See the point I make above about accurately detecting every error case, and providing users with relevant error messages and ideally suggestions for fixes. It seems to me that the problem is fundamentally the load command, since it does not know what the user wants to do, beyond send to hardware - to me that's just too dumb for modern hardware. Sometimes a user *only* wants to load into RAM, other times she *only* wants to load into flash, but without any way to specify that intent in the gdb load command the sections can't be relied upon to detect what is actually a very simple error condition for the user. It does not matter the least that the error is outside gdb/OpenOCD and actually in the linking process if we can reliably detect it. I don't think we can do that at the moment. Neither in gdb nor OpenOCD. The only quick fix would be to always require an offset to be specified in the gdb load command, and error if it does not match the linking. I'm not sure if that's a great idea but it seems intuitive. The load command would no longer be target agnostic (maybe that's a good thing?) but at least it would still be file agnostic. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
John [st32 flash can be at 0x0 or 0x800, I want to link my code at 0x0...] Is there a specific technical advantage you are gaining? I can't think of any. If there is - please explain. Have you tried the load address in the linker? Hence, the code loads at address(fixed location of flash) and runs at (aliased location) Here's an example of the load address technique. http://lostarm.svn.sourceforge.net/viewvc/lostarm/trunk/chips/at91sam7x256/source/at91sam7x256_ld?revision=28view=markup Examples are on line 68, 79, 196, etc. [ A note of magic, on the linker command line, the variable: __layout_flash is set to 0 or 1] -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Sat, Sep 4, 2010 at 7:31 PM, Peter Stuge pe...@stuge.se wrote: Andreas Fritiofson wrote: When gdb is asked to load an image it simply writes all relevant sections in that image to their respective memory locations. If it has knowledge that the location to be written resides in flash, it uses the vFlash* commands, otherwise it uses regular memory writes. Thanks! Sorry I'm a bit of a gdb noob. I've never used it in-depth in spite of using it a little, over lots of years. If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. I disagree; gdb can certainly discover this and do something more useful (error message, whatever) than trying to send stuff to OpenOCD *even though* it can not work. GDB cannot know that it cannot work. The user has, and must have, the power here. If the user tells gdb to load some data to address 0, gdb must try its best to do so, using the information provided (directly or indirectly) by the user to determine _how_ to do it. I know I would hate if gdb tried to outsmart me by disallowing a load of a not-quite-standard configuration just because it doesn't work in other cases. Yes, you can fix the error by telling gdb to load the image with an offset. What happens then, exactly? Does gdb relocate all sections or does it just send a single offset parameter to OpenOCD? I really don't know since I've never used the offset. It's probably mainly useful when you load a binary file without location information encoded in the file. When you load an elf-file, all information gdb needs is already available from the file. Under normal circumstances, load is a fire-and-forget command, it just does the right thing. Very usable. That won't change the fact that the image is not linked correctly Agreed. and gdb can hardly be blamed for providing the possibility of a workaround. If anything I'm blaming gdb for not being smarter about when to automatically add the workaround - or at the *very least* providing relevant and useful error messages. THE workaround you're talking about is not some universal fix for problems related to linking. It may help in some very specific situation with some link script that's broken in a very specific way. It can never be made automatic. Consider if my target actually HAS some memory at address zero that I want to load and gdb has been patched as a result of this discussion to automatically add 0x800 to the load address if it equals zero. It would break my system. Can you find another method of altering gdb that would resolve this issue while not breaking any conceivable valid configuration and not producing nonsense error messages? Nor is it an OpenOCD problem. .. We can't guess the user's intentions And we shouldn't. We can't really tell the (non-flash) loads from other memory writes and we don't want to see errors on every write to peripheral or sram addresses. Even if we could we wouldn't want to print an error, because there is no error. There is not enough information for OpenOCD to accurately determine if it is an error or not. Remember that is very different from there is no error. Even in gdb there may not be enough information, since the load command is so generic. It seems you're trying to load an image to a memory location not commonly used for loading to. Maybe you're using a broken linker script. A message similar to this would be a significant and real improvement if it could be generated with zero false positives. It cannot. Do you want me to try to fix the script for you? Silly. At most, whoever is generating the error (gdb IMO) could at this point list known memory areas. That would be neat. Why not take it a step further? .. We shouldn't remove the incentive for users to fix their tools or read up on the docs by reducing the impact of their errors or making it easier to work around them. Let me make another point, which I think is partially parallell partially orthogonal: There should be adequate error messages for all error cases. All error cases must be detected without heuristics and without ambiguity. A bit too ambitious goal, don't you think, especially when you consider errors that are not errors in the realm of gdb, but outside of it. It's like a blender that would refuse to mix ingredients that are not normally used together. But ideally this knowledge should be up in gdb too, OpenOCD already gives gdb full knowledge of the target's memory layout (at least what is and isn't flash). Good stuff. The problem is all in gdb then. No, the problem is still in the faulty linker script/build system shipped by Olimex(?). Use a Blinky LED example from another source and the issue is gone. Freddie Chopin wrote: Both OpenOCD and GDB work perfectly well with correct files (standard OpenOCD .cfgs, correctly linked .elf file) so I really don't see any problem you're trying to fix... Usability.
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. I disagree; gdb can certainly discover this has, and must have, the offset. It's GDB runs by the memory map that OpenOCD feeds it during startup. That memory map is not, ISTR, necessarily correct about where ram is found. There's an RFE in our bug database about wanting to at least add a way to declare where RAM lives, so that can be fed to GDB.. probably mainly useful when you load a binary file without location information encoded in the file. When you load an elf-file, all information gdb needs is already available from the file. Sometimes. If it was part of the linker script used to create the ELF image. There don't seem to be public archives of linker scripts for Cortex-M parts, specifying where flash and SRAM regions are found. So folk need to write their own (possibly buggy) ones... It can never be made automatic. Consider if my target actually HAS some memory at address zero that I want to load and gdb has been patched as a result of this discussion to automatically add 0x800 to the load address if it equals zero. It would break my system. Can you find another method of altering gdb that would resolve this issue while not breaking any conceivable valid configuration and not producing nonsense error messages Download comoplete target memory maps to GDB, not the partial (and ISTR made-up/wrong) one it now delivers ... Knock off that RFE... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
Shooting from he hip: what about the offset to gdb's load command? Could that help? -- Ø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] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
The syntax of load with an offset is also a bit annoying: But it does what you need? -- Ø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] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
On Fri, Sep 3, 2010 at 9:29 PM, John Hartman (NoICE) j...@noicedebugger.com wrote: The STM32 parts have Flash beginning at 0x800, and OpenOCD's stm32x.c places the Flash there regardless of the address used in the flash command in the cfg file. The chips have two pins that can be jumpered to specify what appears at address 0: Flash, RAM, or the boot loader. For embedded work, I think Flash will be the most common case. But if I link my program at zero, it is a pain to burn my program, because OpenOCD tells gdb there is only RAM at 0, with Flash at 800. One solution is to re-link my program to 800, and rely on aliasing of the vector table to 0. This works, but is a little annoying. Annoying how? The flash IS at 0x0800. Why would you want to link your program to 0? That if anything would be relying on the aliasing. Of course it works, otherwise the chip couldn't start, but does it alias the entire flash and not just enough to cover the vectors? Two years ago, the ST folks I asked didn't know the answer to that. Perhaps it's clarified in the docs today. I would like to propose the following changes to allow Flash at zero: 1) In the file flash/stm32x.c, function stm32x_probe, remove or comment out the explicit setting of bank-base: // Don't fill in the base: get it from the cfg file // bank-base = 0x0800; bank-size = (num_pages * page_size); (etc.) 2) In the stm32.cfg, change flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME to flash bank $_FLASHNAME.1 stm32x 0x 0 0 0 $_TARGETNAME flash bank $_FLASHNAME.2 stm32x 0x0800 0 0 0 $_TARGETNAME This claims that there are TWO Flash banks, one at 0 and one at 800. By having two banks, users can locate their code at either location, as they prefer, without needing to modify the cfg file. Note that this would break existing cfg files, moving the Flash from 800 to 0. This could be remedied by using a non-zero value for one of the other parameters (bus width etc) to mean new style, and only using the specified base address in that case. (Or more formally, one might add a new algorithm instead of stm32x that does this) What do people think? Breaking existing config files and/or adding confusing nonexistent banks for no apparent benefit? I don't like it. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 02:48 PM 9/3/10, Ãyvind Harboe wrote: Shooting from he hip: what about the offset to gdb's load command? The short answer is I didn't know that gdb's load HAD an offset. The longer answer is that gdb may be invoked by Eclipse, Insight, CodeBlocks etc. In that case, specifying an offset is at best yet another configuration step that must be done. At worst, the GUI may not support adding such parameters. The syntax of load with an offset is also a bit annoying: Normally, the tools invoke gdb specifying the file to be debugged. Then the GUI issues gdb commands like target remote localhost: load To specify an offset on the load command, I have to re-specify the file load mypath/myfile.elf 0x800 So the configuration string now depends on the program being debugged. Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 03:30 PM 9/3/10, Ãyvind Harboe wrote: But it does what you need? Yes. My hope was to move from possible to configure to easy to use. But it is certainly possible to use load with an offset. Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 03:32 PM 9/3/10, Andreas Fritiofson wrote: Annoying how? The flash IS at 0x0800. Why would you want to link your program to 0? That if anything would be relying on the aliasing. Of course it works, otherwise the chip couldn't start, but does it alias the entire flash and not just enough to cover the vectors? Two years ago, the ST folks I asked didn't know the answer to that. Perhaps it's clarified in the docs today. I have found Flash-at-zero to be the common case for ARM7 from many vendors. Sometimes a register must be written to map the entire Flash at 0, more often 0 is the default. Perhaps this is not the case on Cortex - the STM32 is my only experience there. My first test project for STM32 was an LED-flasher program that Olimex ships with their STM-P103 board. It links at zero. I do not claim that this is the best project in the world, but it will be the first one that many people see, and it will not work as provided. The memory map diagram in the 3 June 2010 update to the STM32F103 datasheet labels the entire range 0 to 800_ with Aliased to Flash or system memory depending on BOOT pins. Whether or not this is accurate, I cannot say. My intent was to make it easier for people to get gdb and OpenOCD running. The volume of how do I do it traffic here and on SparkFun indicates to me that things could be made easier. But if the change seems unwise to the expects, I am happy to withdraw my proposal. Best regards, John Hartman ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
John Hartman (NoICE) wrote: My intent was to make it easier for people to get gdb and OpenOCD running. The volume of how do I do it traffic here and on SparkFun indicates to me that things could be made easier. This is a good initiative, but I think it's important to consider the different components involved. But if the change seems unwise to the expects, I am happy to withdraw my proposal. I like your goal, but I don't think OpenOCD should be working around the behavior of gdb, or even higher level tools. Better just fix gdb or the other tools. Does the gdb load command (with or without parameters) always send an address to OpenOCD? If so, then gdb obviously also needs to know the address it should send. That could come from the user, from another tool, or from the binary. Adding an alias to OpenOCD isn't the right fix to the problem of users or tools interfacing with gdb but not telling gdb the whole story IMO. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
