[Openocd-development] STM32F215RG tested OK, but 0x1FFFF7E0 is not for flash_sram size now
Hi, I'm just start to test STM32F2. Please make sure the location of flash_sram_size register. -- Best Regards, SimonQian http://www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bitbus
Am 04/19/2011 04:59 PM, schrieb Rogan Dawes: > Hi *, > > So it seems that there is something more seriously wrong. I tried to > write to one of the sectors that was shown as unprotected (per "flash > info 0" output), using the following command: > > openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log \ > -c "flash probe 0" \ > -c "flash info 0" \ > -c "flash erase_address pad unlock 0x 0x1" \ > -c "flash write_image erase unlock mtdblock4-3 0x" \ > -c "shutdown" > > That failed with the following error: > > Error: 348629 73825 cfi.c:1808 cfi_spansion_write_block(): flash write > block failed status: 0x0 > Error: 348630 73825 core.c:98 flash_driver_write(): error writing to > flash at address 0xff80 at offset 0x007f > Debug: 348631 73825 command.c:638 run_command(): Command failed with > error code -902 > User : 348632 73826 command.c:679 command_run_line(): Command handler > execution failed > in procedure 'flash' > > The detailed log file is at: > > http://dawes.za.net/rogan/openocd-20110419-1625.log.gz > > Any ideas on what I can do to debug this further? Try removing the working area from your config - that will force OpenOCD to run single-cycle accesses from the host, without relying on target-based code or RAM. It will be dead slow (on the order of some 10 bytes/s), but you can trace the individual accesses and see what goes wrong. And if nothing goes wrong, you have a (slow) recovery method, and you know that your memory / working area setup is wrong. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bitbus
Hi *, So it seems that there is something more seriously wrong. I tried to write to one of the sectors that was shown as unprotected (per "flash info 0" output), using the following command: openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log \ -c "flash probe 0" \ -c "flash info 0" \ -c "flash erase_address pad unlock 0x 0x1" \ -c "flash write_image erase unlock mtdblock4-3 0x" \ -c "shutdown" That failed with the following error: Error: 348629 73825 cfi.c:1808 cfi_spansion_write_block(): flash write block failed status: 0x0 Error: 348630 73825 core.c:98 flash_driver_write(): error writing to flash at address 0xff80 at offset 0x007f Debug: 348631 73825 command.c:638 run_command(): Command failed with error code -902 User : 348632 73826 command.c:679 command_run_line(): Command handler execution failed in procedure 'flash' The detailed log file is at: http://dawes.za.net/rogan/openocd-20110419-1625.log.gz Any ideas on what I can do to debug this further? Thanks Rogan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] cortex a9: merge cortex a9 and a8 code
+++ Øyvind Harboe [2011-03-22 09:23 +0100]: > On Tue, Mar 22, 2011 at 9:18 AM, Tomek CEDRO wrote: > > > > On Tue, Mar 22, 2011 at 6:22 AM, Øyvind Harboe > > wrote: > > > cortex a8 and a9 are very similar, so they should be merged and > > > conditional code used + configuration options. > > > > > > cortex m3 is more mature(hence breakage is more of an issue) and > > > much more different so merging *all* cortex code is further down the > > > road. > > > > Aaah, maybe "cortex_m.c" and "cortex_a.c" then? :-) > > Sounds sensible to me. Yep - this is in line with how the chip families are designed (and marketed). At some point we might find we can't accomodate all cortex-A CPUs in one file (don't know how much they changed re JTAG in A15, for example), but until then it makes sense to treat them as a closely-relate family. Then we have separate Cortex R and Cortex M support. Now that I'm inside ARM I poke people about OpenOCD when I get the chance. The people here have lots of access to the really expensive stuff so openOCD is not that high on the radar, but it is known about and isn't being entirely ignored, which is a good start. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error
Merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC32XX Nand support
Merged. Thanks! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bitbus
[Apologies for duplicates, I used the wrong address to send to the list] Not sure which protection mechanism applies to me, as I have overwritten these segments before using uboot. (That's what got me into this mess in the first place! :-) ) I certainly did not apply 12V manually. Rogan --Original Message-- From: Mathias K. To: Rogan Dawes Cc: Michael Schwingen Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bitbus Sent: Apr 19, 2011 09:24 Hello, there are several mechanism to protect or unprotect the sectors (factory/customer). If the "Secured Silicon Sector" locked you need 12V at the reset pin to execute the "Temporary Sector Group Unprotect" command. If the "Secured Silicon Sector" not locked you are able to unlock the sectors permanently inside the "Secured Silicon Sector Command Sequence". Regards, Mathias Am 19.04.2011 07:37, schrieb Rogan Dawes: > On 2011/04/18 10:00 PM, Michael Schwingen wrote: > >>> Any ideas why the flash unprotect might fail? >> AFAIR, this is not implemented for AMD/Spansion parts, since these parts >> never had any protection mechanism when they started. >> In Contrast, many Intel flashes come up protected out of reset and >> *need* the unprotect operation. >> >> Are you sure your flash *does* have protection and *needs* unprotect? >> >> Otherwise, you can simple remove the "unprotect" option. >> >> cu >> Michael > > Hi Michael, > > Well, "flash info 0" shows that certain sectors are protected and that others > are not, which > suggests that protection is actually present and implemented in this > particular chip. > > I'll try to dig into this in a bit more detail. > > Thanks > > Rogan > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cortex_a :smp feature
Could you create a patch to openocd.texi? type "make pdf" => generates doc/openocd.pdf -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cortex_a :smp feature
Hello, Here is some documentation. 1.OPENOCD NEW COMMAND 1.1 TARGET NEW COMMAND smp command in target, allows to group the target working in smp. target smp targetname1 targetname2 targetname3 ... all target have different coreid targetname1 has coreid 0 targetname2 has coreid 1 targetname3 has coreid 2 ... With this command only one gdb session is created for the list of target. 1.2 CORTEX_A NEW COMMAND As follow, here is the list of additional commands for target cortex_A (This commands apply to the current target (cortex_a8)) 1.2.1 cortex_a8 smp_on following this command, the behavior is as follow. - the set of hardware breakpoint => the same hardware break point is set on all target list. - halt command => trigger the halt of the other target - resume command => trigger the write of context of all target in the list, the restart of current target launch the restart of the other. - a dedicated gdb command is implemented for switching the target displayed by the gdb session see 2. - following a breakpoint: the target stopped by the breakpoint is displayed to the gdb session. 1.2.2 cortex_a8 smp_off The current target is the one displayed in the gdb session, only this target is controlled, this behavior is needed during system boot (u-boot for instance) 1.2.3 cortex_a8 smp_gdb Display/fix the target number displayed in gdb instance This command is mainly for testing. example : >cortex_a8 smp_gdb gdb coreid 0 -> -1 0 : coreid 0 is displayed to gdb ,-> -1 : next resume triggers a real resume > cortex_a8 smp_gdb 1 gdb coreid 0 -> 1 0 :coreid 0 is displayed to gdb ,->1 : next resume displays coreid 1 to gdb > resume > cortex_a8 smp_gdb gdb coreid 1 -> 1 1 :coreid 1 is displayed to gdb ,->1 : next resume displays coreid 1 to gdb > cortex_a8 smp_gdb -1 gdb coreid 1 -> -1 1 :coreid 1 is displayed to gdb, -1 : next resume triggers a real resume 2.GDB PROTOCOL ADDSON FOR DISPLAYING OTHER CORE CONTEXT It is a copy paste of explanations from src/target/smp.c /* implementation of new packet in gdb interface for smp feature */ /* */ /* j : smp status request */ /* J : smp set request */ /* */ /* jc :read core id displayed by gdb connection */ /* reply core id is int32_t , 8 hex digits */ /* */ /* Reply ENN error not supported (target not smp)*/ /* */ /* JcXX set core id displayed at next gdb continue */ /* maximum 8 bytes described core id int32_t (8 hex digits) */ /* (core id -1 , reserved for returning to normal continue mode) */ /* Reply ENN error not supported(target not smp,core id out of range) */ /* Reply OK : for success */ /* */ /* handling of this packet within gdb can be done by the creation */ /* internal variable by mean of function allocate_computed_value */ /* set $_core 1 => Jc01 packet is sent*/ /* print $_core => jc packet is sent and result is affected in $ */ /* Another way to test this packet is the usage of maintenance packet */ /* maint packet Jc01 */ /* maint packet jc Example in a .gdbscript for a target with 2 core having id 0 and 1 (u8500) /* force the display of coreid 0 */ define toggle0 maint packet Jc0 continue maint packet Jc-1 end /* force the display of coreid 1 */ define toggle1 mmaintenance packet Jc1 continue maintenance packet Jc-1 maint packet jc end 3. GDB RESET PACKET USAGE Example of script for resetting target in gdb (u8500) define reset maintenance packet R maintenance packet Jc0 continue maintenance packet Jc-1 end -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Tuesday, April 19, 2011 10:11 AM To: Michel JAOUEN Cc: Tomek CEDRO; luca ellero; openocd-development@lists.berlios.de Subject: Re: [Openocd-development] cortex_a :smp feature Hi Michel, thanks for the effort here! Could you write some documentation? I'd like to let these patches cool off and leave some time for feedback. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.
Re: [Openocd-development] cortex_a :smp feature
Hi Michel, thanks for the effort here! Could you write some documentation? I'd like to let these patches cool off and leave some time for feedback. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error
Looks like a reasonable fix to me. Any objections? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error
Thanks Michel, I hadn’t had time to investigate it. Evan -Original Message- From: Michel JAOUEN [mailto:michel.jao...@stericsson.com] Sent: Tuesday, 19 April 2011 5:59 PM To: Evan Hunter; Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: RE: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error Hello, I noticed a compilation error on rtos in linux 64 bits. Here is an attached patch. Best Regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error
Hello, I noticed a compilation error on rtos in linux 64 bits. Here is an attached patch. Best Regards 0001-rtos-compilation-error-on-amd64.patch Description: 0001-rtos-compilation-error-on-amd64.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bit bus
Hello, there are several mechanism to protect or unprotect the sectors (factory/customer). If the "Secured Silicon Sector" locked you need 12V at the reset pin to execute the "Temporary Sector Group Unprotect" command. If the "Secured Silicon Sector" not locked you are able to unlock the sectors permanently inside the "Secured Silicon Sector Command Sequence". Regards, Mathias Am 19.04.2011 07:37, schrieb Rogan Dawes: > On 2011/04/18 10:00 PM, Michael Schwingen wrote: > >>> Any ideas why the flash unprotect might fail? >> AFAIR, this is not implemented for AMD/Spansion parts, since these parts >> never had any protection mechanism when they started. >> In Contrast, many Intel flashes come up protected out of reset and >> *need* the unprotect operation. >> >> Are you sure your flash *does* have protection and *needs* unprotect? >> >> Otherwise, you can simple remove the "unprotect" option. >> >> cu >> Michael > > Hi Michael, > > Well, "flash info 0" shows that certain sectors are protected and that others > are not, which > suggests that protection is actually present and implemented in this > particular chip. > > I'll try to dig into this in a bit more detail. > > Thanks > > Rogan > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
