Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Gary Carlson wrote: 1) One of the features that the software currently allows is configuration setting inheritance from board to target to CPU. While I generally am a big advocate of extensibility in most software projects, I have been very leery of doing this for hardware-specific configuration files. Over every person's career, many of battle scars are left behind. And I have many on mine that were related to nightmare debugger/emulator configuration problems where I tried to inherit one thing from another. The one danger with inheritance in this particular scenario is many people will see a target and naturally glom onto it without giving too much thought about the consequences. Many processor families have rather incestuous relationships that share many common details, but inevitably have differences -- often very subtle ones. These little details, however, sometimes generate big consequences. The other danger always lurking with the current approach is that it is entirely possible one developer can make a change to the underlying root target file without realizing that it may propagate undesirable changes into higher-level board files. Unfortunately these type of issues are not typically discovered until much later. For these two reasons, I wonder if it may not make more sense at some point to discourage target configurations all together and encourage self-sufficient board-level configuration files instead, even though this normally goes against the grain of extensibility. The key to making this work would be to break the directory structure along processor models/manufactuer (i.e. arm926-ejs/atmel) and then lump individual board configuration files under the appropriate directories. If a developer plans on using a particular processor in a design that doesn't have an existing debugger configuration file, they quickly know which board configuration files are likely to be similar and then clone it with little risk of clobbering something else. I don't think that would be a good idea. I see the problem, but your approach would lead to several board config files that contain almost identical copies of the target specifications, leaving the user to find out the differences and wonder *why* something was put different in a special config. 2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. That sounds good. 3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. To enforce rules on target scripts, we first need to have some rules to enforce against. I suggest that you start writing up a patch against the OpenOCD documentation on requirements for target config scripts. The other problem I have with this is that I want as many scripts as possible, even if they are crummy Perhaps we could mark or name scripts that don't follow the rules as work-in-progress? I.e. either it needs to have all the right comments features, or it needs a work in progress note at the top? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? set xyz_register 0x3ec2 set abc_magic_value 0x12341234 ... mww $xyz_register $abc_magic_value #or mww $xyz_register 0x02 Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
I can now see that I left off a critical detail! :) Yes, you most certainly can use a TCL set command to accomplish this. The only issue is you have to spend an inordinate amount of time entering the values by hand. That in itself is another source for errors -- especially on processors with large configuration register sets. Most processor manufacturers typically provide a standard C include file with their reference projects that have all the configuration registers and their relevant addresses pre-defined. What I was thinking was something that allows a person to capitalize off existing C header files directly in the form of a special TCL include statement. I am not too familiar with how the existing TCL parser works, so this idea may be impractical, however. Gary On 9/1/09 12:12 AM, Magnus Lundin lun...@mlu.mine.nu wrote: 3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? set xyz_register 0x3ec2 set abc_magic_value 0x12341234 ... mww $xyz_register $abc_magic_value #or mww $xyz_register 0x02 Best regards, Magnus ___ 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] FW: AT91SAM9G20-EK.cfg
On 9/1/09 12:04 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: 2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. To enforce rules on target scripts, we first need to have some rules to enforce against. I suggest that you start writing up a patch against the OpenOCD documentation on requirements for target config scripts. The other problem I have with this is that I want as many scripts as possible, even if they are crummy Perhaps we could mark or name scripts that don't follow the rules as work-in-progress? I.e. either it needs to have all the right comments features, or it needs a work in progress note at the top? I can definitely see your perspective of trying to get as many configuration files as possible. There is some truth to what you said earlier about quantity over quality in the startup phase of any project. In some ways it is not too much different then a dating site. If you only have two singles signed up, getting additional people to subscribe to the service may be difficult. This idea I think has merit for the long term, but maybe leaving things unchanged for now makes better sense. Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Crazy idea: - write a small C app for the target that goes along with board config file - this .elf file is loaded by OpenOCD - use built-in ARM simulator to execute fn's in that .elf file ? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Øyvind Harboe wrote: Crazy idea: - write a small C app for the target that goes along with board config file - this .elf file is loaded by OpenOCD - use built-in ARM simulator to execute fn's in that .elf file What advantage does that provide? You need a disassembler to view the effective board-init sequence, you need a cross-toolchain to modify the code, in comparison to just changing a script file. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
On Tue, Sep 1, 2009 at 10:24 AM, Michael Schwingenrincew...@discworld.dascon.de wrote: Øyvind Harboe wrote: Crazy idea: - write a small C app for the target that goes along with board config file - this .elf file is loaded by OpenOCD - use built-in ARM simulator to execute fn's in that .elf file What advantage does that provide? You need a disassembler to view the effective board-init sequence, you need a cross-toolchain to modify the code, in comparison to just changing a script file. You can use the header files for the target file without having to port the existing C code to OpenOCD init code. One way to sidestep writing init sequences that I use, is to write a small piece of code to flash (somehow, possibly very slowly without working memory), run u-boot, or somesuch. then I reset run + halt the CPU and issue a load to load an application into RAM. I prefer a nice crisp self-contained init sequence to the above approach any day though. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Øyvind Harboe wrote: What advantage does that provide? You need a disassembler to view the effective board-init sequence, you need a cross-toolchain to modify the code, in comparison to just changing a script file. You can use the header files for the target file without having to port the existing C code to OpenOCD init code. Hm - yes, that might be useful. I have used objdump to extract the initialization tables from my board-init code to create BDI2000/OpenOCD init scripts. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Hm - yes, that might be useful. I have used objdump to extract the initialization tables from my board-init code to create BDI2000/OpenOCD init scripts. Now, if we could do that in some *nice* way it would be quite a powerful method. Most every PCB out there has some working sample code -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FW: AT91SAM9G20-EK.cfg
Hi Øyvind, Yes, you are absolutely correct that configuration files are a lot of work to put together. And I might add critical too! :) One of the things I wanted to do is throw out some ideas for everyone to think about as possible improvements to this configuration file development process. Some of the ideas are philosophical and don't have a right or wrong answer. They really are more intended to provoke a thoughtful discussion even if they are never implemented: 1) One of the features that the software currently allows is configuration setting inheritance from board to target to CPU. While I generally am a big advocate of extensibility in most software projects, I have been very leery of doing this for hardware-specific configuration files. Over every person's career, many of battle scars are left behind. And I have many on mine that were related to nightmare debugger/emulator configuration problems where I tried to inherit one thing from another. The one danger with inheritance in this particular scenario is many people will see a target and naturally glom onto it without giving too much thought about the consequences. Many processor families have rather incestuous relationships that share many common details, but inevitably have differences -- often very subtle ones. These little details, however, sometimes generate big consequences. The other danger always lurking with the current approach is that it is entirely possible one developer can make a change to the underlying root target file without realizing that it may propagate undesirable changes into higher-level board files. Unfortunately these type of issues are not typically discovered until much later. For these two reasons, I wonder if it may not make more sense at some point to discourage target configurations all together and encourage self-sufficient board-level configuration files instead, even though this normally goes against the grain of extensibility. The key to making this work would be to break the directory structure along processor models/manufactuer (i.e. arm926-ejs/atmel) and then lump individual board configuration files under the appropriate directories. If a developer plans on using a particular processor in a design that doesn't have an existing debugger configuration file, they quickly know which board configuration files are likely to be similar and then clone it with little risk of clobbering something else. 2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. Here again, it is possible for another developer to come along and use a script with another debugger, find something that appears to be a bug, and make a fix for their particular setup that now breaks it for the original setup. If for some reason, the approach described in 1) is adopted in the future, the approach could further be extended by creating additional subdirectories for emulator and version. For example, the configuration file I created would be filed under arm926ejs/atmel/at91sam9g20-ek/sam-ice/v8/file.cfg or something similar. This way if a developer is using a future version 123 dongle that has new quirks, there is less risk of corrupting older debugger configurations that other people may still be using. 3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Anyway like I said, these ideas I propose are just that and nothing more. I realize that other good arguments exist for keeping things the way they are and there is nothing wrong with that either. And admittedly, the ideas I propose here have their own share of thorns too! Food for thought! :) Gary On 8/31/09 2:09 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Committed. Thanks! I think you are raising an important point: these configuration files can be a *LOT* of work to put together and hard work too... I don't know of a shortcut, other than to try to build an extensive library of quality config files. Of course I'd like all the config files to be of top quality tested by multiple developers, but quantity has a quality all of it's own... We see evidence that bad config files are being incrementally improved by patches, hence I prefer to get them committed sooner rather than later.
