On Wednesday 03 February 2010, Harald Kipp wrote: > Like I've done in my last patch for ethernut3/at91r40008 I'd like to > clean-up the eir/sam7se512 combo. I'm not sure, how to do this in detail > and would appreciate any advice. > > 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. > Another idea is to follow at91sam7sx.cfg and create a more general file > named at91sam7sex.cfg for all 3 members of this family. However, the > chip IDs (CPUTAPID) differ: > > 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.) > Worse, they come with different RAM sizes and therefore possibly > different work area layouts. 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. (Though the sam7 flash driver might need minor tweaks, like those I committed for the Stellaris flash driver a while back, if it's got any tendancy towards stupidly over-allocating work area.) 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. It's kind of nasty to be reporting un-educated guesses about SRAM for GDB's memory map... > Shall we specify all these variants (other devices may have others) in > each board configuration files? That can work, if no better option surfaces. > Btw. this is also true (or actually wrong) for target/at91sam7sx.cfg, > which specifies 16k work area size. The AT91SAM7S32 has 8k and the > AT91SAM7S16 only 4k of RAM. The at91sam7sx is not as general as it claims. > > 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...) But shouldn't that be "sam7se"? The "x" is significant in Atmel's naming scheme, and "sex" annoys lots of puritanical spam filters. ;) 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. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
