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 0xffff3ec2 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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
