Freddie>> [[ use the flash bank info ]]
duane>> I don’t see where OpenOCD knows this.
Paul>> target with supported flash you already have "flash bank …"
Thanks that helped me find the link.
There are two lists List (TARGET) - the list of all targets, and
List(FLASHBANKS) They are not directly linked together hence I did not find
them, I was looking at it from the target structure only. Turns out BANK has
a target pointer, one must traverse the the list of BANKs to find the matching
target.
So yes, you could - scan the flash bank target and determine BKPT_TYPE
Paul>> What do you think, do you see any downsides with this?
Concerns:
a) Masked rom - is not flash - how do you specify that range? Example: Many
M3s have a small masked rom ‘boot loader’ you want to step through and debug.
b) A target that FLASH programming is not supported by opened, thus you program
the FLASH by other means …
c) A target where something else {example: boot loader, or band-boot hardware}
loads a stub into CODE ram - and you need to treat that area as a “pseudo rom’.
Example Freescale imx25 - boot from SPI/NAND - the flash header specifies where
boot code is loaded into memory. The ROM_BOOT - loads a small chunk into on
chip RAM, then jumps to that RAM location.
As for an implementation method, the closest function is:
get_flash_bank_by_address() -
Issues with using that function
Concern (above-A) The related area might not have a flash bank structure over
that area.
Concern (new) - we don’t want to “probe” the flash area when we are determining
breakpoint type.
Could write a new function - something like: flash_IsThisAddressInFlash(
target_pointer, ADDRESS ) this would *NOT* probe anything
Do you see a problem with assuming the “flash address range” is always valid if
not auto-probed?
Result IDEA:
1) [my original idea]
Create hw-breakpoint-region structure *in* the target structure.
Allow user to add additional address ranges to this structure.
2) [Make use of Flash Bank as a secondary means]
Provide a means to also use the FLASH BANK as an additional test.
It cannot probe: That will cause other problems!
What do you think of that?
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel