David Brownell wrote: > On Wednesday 03 February 2010, Harald Kipp wrote: >> The first thing I want to do is to move the target file from >> sam7se512.cfg to at91sam7se512.cfg. So far, board/eir.cfg seems the only >> one referencing that target. However, it may break existing private user >> scripts. Shall we keep sam7se512.cfg as >> >> source [find target/at91sam7se512.cfg] >> >> ? > > I'd think so. An "at91" prefix is kind of superfluous. > If we were doing it from scratch, having it might be nice; > but at this point we should bias towards compatibility. > > The "sam7..." name doesn't break anything, and it matches > the common usage I've heard.
Not sure whether I was not clear enough or if I misunderstood your reply. What I wanted to say is, to keep sam7se512.cfg, but only as a 1-liner, including the new file named at91sam7se512.cfg. Right now only the sam7se512 and the sam7x256 omit the at91 prefix, all other members of the at91sam family make use of it. While the list is growing, it may become more difficult to spot the right file. >> AT91SAM7SE32 0x27280340 >> AT91SAM7SE256 0x272A0940 >> AT91SAM7SE512 0x272A0A40 > > That's a bit of a problem. But it's workable by having a common config > file for everything except those IDCODE values ... define the IDCODE > in a chip-specific file, then source the common file. (You mention > that "common file" strategy later.) Sorry, I accidentally referred to the chip IDs of the debug unit. The JTAG ID code registers also differ (datasheet pg. 54) among the three variants of the SAM7SE. Most confusing, OpenOCD retrieves 0x3f0f0f0f, which looks completely wrong to me. Anyway, the CPUTAPID that is currently set in the existing configs, seems to work for all SAM7 devices and even the STR7. Looks like I missed something. > Re layout, if the RAM starts at the same location they can likely > default to the same work area layout. It's not like most downloaded > algorithms need a lot of work area; even just 4K should suffice. OK. > I thought Atmel was pretty good about exposing that sizing information > through chip registers. If the flash driver (the main SoC-specific code) > can autodetect that (some DBGU-related registers?) it should be able to > use a feature that's been discussed a bit: automagically declaring the > SRAM region, as well as the flash regions. This should be possible with the SAM7 as well. >> I'd prefer to create >> >> at91sam7se32.cfg >> at91sam7se256.cfg >> at91sam7se512.cfg >> >> Possibly they may then include >> >> source [find target/at91sam7sex.cfg] > > As I say, that can work. Likely it's needed because of the IDCODE issues. > (Bugfixes in that area would still be appropriate for the 0.4 release...) I will see, what I can do. > But shouldn't that be "sam7se"? The "x" is significant in Atmel's naming > scheme, and "sex" annoys lots of puritanical spam filters. ;) I tried to be a good boy before posting and studied previous threads on this topic. ;-) http://www.mail-archive.com/openocd-development@lists.berlios.de/msg07617.html > By the way ... not that I'd expect Atmel to phase out their sam7 lines > any time soon, but it's interesting that some of their new sam3s chips > are pin-compatible with some of the sam7 chips. As if they're getting > ready to de-emphasize the arm7tdmi cores in favor of cortex-m3, if their > customers start preferring those newer cores. The embedded world is not that short-living as the PC world. Even the ancient AT91R40008 is still selling well. Thanks for taking the time to look into my suggestions, Harald _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
