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
On Sat, Sep 4, 2010 at 7:31 PM, Peter Stuge 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 .cf
Re: [Openocd-development] current windows gdb gui options
I have had some success with Code::Blocks on Windows. On Linux it works fine. On Windows there are a few annoyances. The main one is how to halt remote targets. With OpenOCD I do it through the telnet interface. See the discussion at http://forums.codeblocks.org/index.php/topic,12412.0.html. Phil - Original Message > From: Duane Ellis > To: OpenOCD Development > Sent: Sat, September 4, 2010 4:04:29 AM > Subject: [Openocd-development] current windows gdb gui options > > For years, I have used "gdb-insight" - (the Tcl/Tk version of GDB) > > http://sourceware.org/insight/ > > However, it has grown long in the tooth, and cygwin has moved on. > > At this point, the changes in Cygwin have broken the private copy of Tcl/Tk >(from 2004), > Some notes: > > Insight has always had a private copy of Tcl/Tk > Tcl/Tk dropped cygwin support years ago > > GDB/Insight no longer builds, and looks painful to fix. > > Q: What are the openocd + gdb + windows users using as their GUI front end? > > -Duane. > > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error while writing image
Mike Dunn wrote: > > i keep getting the following error > > > > > flash write_image main.bin.out > > couldn't open main.bin.out > > File not in pwd? Specify the full path to the file. Clarify: Remember it's pwd of OpenOCD. Also when running monitor flash ... from gdb. //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=28&view=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
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
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] current windows gdb gui options
On 2010-09-04 13:04, Duane Ellis wrote: Q: What are the openocd + gdb + windows users using as their GUI front end? Me (and many others) use Eclipse + Zylin plug-in + GDB Hardware Debugging plug-in. 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
On Sat, Sep 4, 2010 at 2:57 PM, Peter Stuge 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
Ø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] current windows gdb gui options
I've made a small plugin to Eclipse, which essentially allows one to launch GDB with a short custom sequence like: target remote xxx:333 monitor reset init load stepi http://opensource.zylin.com/embeddedcdt.html -- Ø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] current windows gdb gui options
> Q: What are the openocd + gdb + windows users using as their GUI front end? I'm using Eclipse CDT. I've tried to push the CDT guys in the direction of supporting launching Eclipse from the command line just like Insight... https://bugs.eclipse.org/bugs/show_bug.cgi?id=39640 -- Ø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
[Openocd-development] current windows gdb gui options
For years, I have used "gdb-insight" - (the Tcl/Tk version of GDB) http://sourceware.org/insight/ However, it has grown long in the tooth, and cygwin has moved on. At this point, the changes in Cygwin have broken the private copy of Tcl/Tk (from 2004), Some notes: Insight has always had a private copy of Tcl/Tk Tcl/Tk dropped cygwin support years ago GDB/Insight no longer builds, and looks painful to fix. Q: What are the openocd + gdb + windows users using as their GUI front end? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
