On Sat, Feb 27, 2010 at 10:51:13AM -0800, David Brownell wrote: > On Saturday 27 February 2010, Mariano Alvira wrote: > > On Sat, Feb 27, 2010 at 09:00:32AM -0800, David Brownell wrote: > > > On Thursday 25 February 2010, Mariano Alvira wrote: > > > > --- > > > > > > Needs a patch comment. > > THat was my attempt at a decent description. When combined with > the "add target/...cfg" summary, folk now have some real information. > In particular it mentions the unusual boot scheme: the flash isn't > "on-chip" NOR (with execute-in-place) but "in-package" serial (which > needs to be shadowed into a relatively large SRAM). > > I don't entirely "get" these chips which execute code from large SRAMs > instead of from NOR flash ... I had understood that the SRAMs use more > power than the NOR flash, so that most microcontrollers minimized the > quantity of SRAM they included (even at the cost of annoying the folk > writing code that might like more SRAM).
Yeah, after working with it I actually really like just running out of RAM. You don't have to flash everytime to test something. Also your "code space" is limitless if you come up with an elf loader or some other kind of swapping/virtual memory thing (no MMU though). Also you get to make the tradeoff between code/data. No more of these 128KB flash things with only 4KB of SRAM. Now you get 96KB of SRAM --- and you can slice it up however you want. And of course, the real benefit of the mc13224v is that it's an ARM7, with a fully integrated 802.15.4 radio (balun and everything, just add a PCB trace for the antenna), and loads of RAM: for under $5. > Well, "handy" doesn't seem sufficient to require everyone using this > chip to have that. > > This is however also sufficiently obvious (though I'd just "halt") > that most OpenOCD users should be able to whip that up easily. Nope. Only obvious if you've used OpenOCD a lot before. Most people get a new board, plug it in/hook it up and run openocd and say "now what?". It would be very nice to say back: "type mc1322x_run blink.bin". > Those are both issues. But more to the point, not everyone using > OpenOCD will need or want that ... and anyone who does need it > can easily craft their own. Well, we are only talking about mc13224v.cfg users here --- and I'm pretty sure everyone of them is going to want that routine. There are similar things for loading/running uboot in sheevaplug, openrd. What's so special about uboot.bin? The answer is that it's handy to just type 'sheevaplug_reflash_uboot_env' and if you have a sheevaplug that's probably something you'll want to do a lot. The same is true here. If you are working with an mc13224v you are going to want to load an image to location 0x00400000 and run it --- a lot. But look, if it means you guys won't take it then I won't include it. If that's the case though it would be nice to have a place for these sorts of "handy" and more UI oriented routines. > (You could "resume 0x00400000" and that would > be just a bit more concise.) Thanks. -Mar. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
