Re: [Openocd-development] Cache L1, L2 on armv7a.
On 10/05/2011 05:32 AM, Michel JAOUEN wrote: Hello, Below , you find the answer to your question : * Is the address supposed to point to the base PL310 address? Yes , you have to provide the physical address of PL310. * Why do you call this operation if the target status is unknown? ðAfter target creation and smp initialization, this operation need to be done only once. ðBy doing it with target in unknow state, It is not performed several time, if operation is done several time, only 1^st call is taken into account. * What does this operation do when called? ðThis operation is initializing the l2 cache handler with external cache PL310. (without this initialization cache l2 is not supported) ðThe number of way is provided as parameter, auto detection is not implemented yet. ðThe effect of this call is seen later on : -1- while reading phys memory through dap apsel 1: a flush of the cache L1 from the cortex A9s and then a flush of unified cache L2 will be done. This will allow to read a consistent physical memory. -2- cortex_a8 cache_info : shows the cache L1 and L2 info Best Regards Michel JAOUEN Michel, Thanks for the explanation, that helped a bunch. With this work then using apsel 1 will guarantee consistent memory. If I write through apsel 0 will the L2 and L1 cache lines also be invalidated? Thanks again, Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cache L1, L2 on armv7a.
On 09/29/2011 09:40 AM, Michel JAOUEN wrote: Hello, I implemented the flush of L1 and L2 cache for cortex_a. I added the support of phys memory access through dap apsel 1, (for this access, a flush is performed, and mmu is disabled) I also implement va_to_pa mechanism for virt_to_phys. For that purpose, I have modified the architecture : Instead of increasing cortex_a.c file, I moved this new support feature to armv7a.c . The reason of this change is to prepare later cortex_a evolution.(A15, A7), that could be implemented in Another file than cortex_a.c relying on a set of function from amv7a file. Best Regards. Michel JAOUEN ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Michel, I am trying to understand what the "cache_config" command does so that I can add this functionality to the Pandaboard. I apologize for the list of questions, but the operation is not clear and I didn't see any documentation for this feature: * Is the address supposed to point to the base PL310 address? * Why do you call this operation if the target status is unknown? * What does this operation do when called? I appreciate any insight you can provide. Thanks, Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] AM/DM37x: Use ICEPick warm reset and include halt when gdb connects.
Using the ICEPick reset seems to allow the processor to be halted sooner
and the halt on gdb connection makes the connect process more robust.
>From a69fdf6a0756633a6b562fda34b2cafb070b393f Mon Sep 17 00:00:00 2001
From: Karl Kurbjun
Date: Sun, 2 Oct 2011 11:41:33 -0600
Subject: [PATCH] AM/DM37x: Use ICEPick warm reset and include halt when gdb connects.
Using the ICEPick reset seems to allow the processor to be halted sooner
and the halt on gdb connection makes the connect process more robust.
---
tcl/target/amdm37x.cfg | 41 +
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/tcl/target/amdm37x.cfg b/tcl/target/amdm37x.cfg
index a6daeab..4fe5124 100644
--- a/tcl/target/amdm37x.cfg
+++ b/tcl/target/amdm37x.cfg
@@ -1,6 +1,6 @@
#
-# Copyright (C) 2010by Karl Kurbjun
-# Copyright (C) 2009-2011 by Ãyvind Harboe
+# Copyright (C) 2010-2011 by Karl Kurbjun
+# Copyright (C) 2009-2011 by Ãyvind Harboe
# Copyright (C) 2009by David Brownell
# Copyright (C) 2009by Magnus Lundin
#
@@ -158,25 +158,34 @@ $_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
$_TARGETNAME configure -event "reset-start" { adapter_khz 10 }
-# Reset needs to be performed in in software.
-# The AM/DM37x TRM (sprugn4b) describes the software reset in detail.
-# PRM_RSTCTRL is described in table 3-425 on page 618. We assert RST_GS
-# (bit 1 (in 31:0) ) to do a warm reset.
+# Describe the reset assert process for openocd - this is asserted with the
+# ICEPick
+$_TARGETNAME configure -event "reset-assert" {
+
+ global _CHIPNAME
+
+ # assert warm system reset through ICEPick
+ icepick_c_wreset $_CHIPNAME.jrc
+}
-# Create a vaiable for the register address
-set PRM_RSTCTRL 0x48307250
+# After the reset is asserted we need to re-initialize debugging and speed up
+# the JTAG clock.
-# Describe the reset assert process: A value of 2 must be written
-# (assert bit 1) to the physical address of PRM_RSTCTRL.
+$_TARGETNAME configure -event reset-assert-post {
-$_TARGETNAME configure -event \
- reset-assert "$_TARGETNAME mww phys $PRM_RSTCTRL 2"
+ global _TARGETNAME
+ amdm37x_dbginit $_TARGETNAME
+ adapter_khz 1000
+}
-# After the reset is asserted we need to re-initialize debugging and speed up
-# the JTAG clock.
+$_TARGETNAME configure -event gdb-attach {
-$_TARGETNAME configure -event \
- reset-assert-post "amdm37x_dbginit $_TARGETNAME; adapter_khz 1000"
+ global _TARGETNAME
+ amdm37x_dbginit $_TARGETNAME
+
+ echo "Halting target"
+ halt
+}
##
# End Target Reset Event Setup:
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] FT2232: Add additional debug information with libftdi when cable connection fails.
This additional output was helpful when debugging a FTDI device with a
broken
EEPROM. I was expecting to connect to a cable with a particular
description,
but the device was not found. This error message would helps quickly
identify
the connection failure.
-Karl
>From 69c031d9c515d9f82f5fd6054d980f7b484c759f Mon Sep 17 00:00:00 2001
From: Karl Kurbjun
Date: Sun, 2 Oct 2011 11:28:11 -0600
Subject: [PATCH 3/3] FT2232: Add additional debug information with libftdi when cable connection
fails.
This additional output was helpful when debugging a FTDI device with a broken
EEPROM. I was expecting to connect to a cable with a particular description,
but the device was not found. This error message would helps quickly identify
the connection failure.
---
src/jtag/drivers/ft2232.c | 56 -
1 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 3cca26d..e248f55 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -2348,7 +2348,7 @@ static int ft2232_init_libftdi(uint16_t vid, uint16_t pid, int more, int* try_mo
}
LOG_DEBUG("'ft2232' interface using libftdi with '%s' layout (%4.4x:%4.4x)",
- layout->name, vid, pid);
+layout->name, vid, pid);
if (ftdi_init(&ftdic) < 0)
return ERROR_JTAG_INIT_FAILED;
@@ -2362,16 +2362,70 @@ static int ft2232_init_libftdi(uint16_t vid, uint16_t pid, int more, int* try_mo
return ERROR_JTAG_INIT_FAILED;
}
+ LOG_DEBUG("Attempting to open FTDI device with the following parameters "
+"from cfg:\n"
+" VID: %04x, PID: %04x, Description: %s",
+vid, pid, ft2232_device_desc);
+
/* context, vendor id, product id */
if (ftdi_usb_open_desc(&ftdic, vid, pid, ft2232_device_desc,
ft2232_serial) < 0)
{
+ struct ftdi_device_list *device_list, *curdev;
+ int ret;
+
if (more)
+ {
LOG_WARNING("unable to open ftdi device (trying more): %s",
ftdic.error_str);
+ }
else
+ {
LOG_ERROR("unable to open ftdi device: %s", ftdic.error_str);
+ }
+
*try_more = 1;
+
+
+ /* We were unable to open the device, so list some useful information
+ * about what we found. This section of code is based on the find_all.c
+ * example in libftdi.
+ */
+ if((ret = ftdi_usb_find_all(&ftdic, &device_list, vid, pid)) < 0)
+ {
+ LOG_ERROR("ftdi_usb_find_all failed: %d (%s)",
+ ret, ftdi_get_error_string(&ftdic));
+ goto device_fail;
+ }
+
+ LOG_ERROR("Found %d ftdi device(s) with VID: %04x, PID: %04x:",
+ret, vid, pid);
+
+ for (curdev = device_list; curdev != NULL; curdev = curdev->next)
+ {
+ /* Limit the scope of these variables */
+ char manufacturer[128], description[128];
+ int i = 0;
+
+ i++;
+
+ /* Try reading strings from the found device */
+ if ((ret = ftdi_usb_get_strings(&ftdic, curdev->dev, manufacturer,
+128, description, 128, NULL, 0)) < 0)
+ {
+LOG_ERROR("ftdi_usb_get_strings failed: %d (%s)\n",
+ ret, ftdi_get_error_string(&ftdic));
+goto device_fail;
+ }
+
+ /* Show the device description */
+ LOG_ERROR(" Device %d Description: %s", i, description);
+
+ }
+
+ /* Cleanup the device list and exit */
+ device_fail:
+ ftdi_list_free(&device_list);
return ERROR_JTAG_INIT_FAILED;
}
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Add in additional ICEPick-C functionality and provide more detailed functions
This patch adds in support to assert warm reset through the ICEPick
controller. The added functionality has been primarily tested on the
AM/DM37x, but it has also been used some on the OMAP4.
-Karl
>From 0347f5ad23786080331ee4d09788c947c7126c28 Mon Sep 17 00:00:00 2001
From: Karl Kurbjun
Date: Sun, 2 Oct 2011 10:52:20 -0600
Subject: [PATCH] ICEPick-C: Add support for warm reset through JTAG controller and provide
finer detail functions.
This sets up simple functions that can later be used to provide additional
ICEPick Operations.
---
tcl/target/icepick.cfg | 109 ---
1 files changed, 102 insertions(+), 7 deletions(-)
diff --git a/tcl/target/icepick.cfg b/tcl/target/icepick.cfg
index da92c9e..40d462c 100644
--- a/tcl/target/icepick.cfg
+++ b/tcl/target/icepick.cfg
@@ -1,21 +1,116 @@
+#
+# Copyright (C) 2011by Karl Kurbjun
+# Copyright (C) 2009by David Brownell
+#
+
# Utilities for TI ICEpick-C ... used in DaVinci, OMAP3, and more.
+# Details about the ICEPickC are available in the AM/DM37x document SPRUGN4M
+
+# create "constants"
+proc CONST { key } {
+
+ array set constant {
+ # define ICEPick instructions
+ IR_BYPASS 0x00
+ IR_ROUTER 0x02
+ IR_CONNECT 0x07
+ IF_BYPASS 0x3F
+ }
+ return $constant($key)
+}
+
+# Instruction to connect to the icepick module
+proc icepick_c_connect {jrc} {
+
+ # Send CONNECT instruction in IR state
+ irscan $jrc [CONST IR_CONNECT] -endstate IRPAUSE
+
+ # Send write and connect key
+ drscan $jrc 8 0x89 -endstate DRPAUSE
+}
+
+# Instruction to disconnect to the icepick module
+proc icepick_c_disconnect {jrc} {
+
+ # Send CONNECT instruction in IR state
+ irscan $jrc [CONST IR_CONNECT] -endstate IRPAUSE
+
+ # Send write and connect key
+ drscan $jrc 8 0x86 -endstate DRPAUSE
+}
+
+#
+# icepick_c_router:
+# this function is for sending router commands
+# arguments are:
+# jrc:TAP name for the ICEpick
+# rw: read/write (0 for read, 1 for write)
+# block: icepick or DAP
+# register: which register to read/write
+# payload:value to read/write
+# this function is for sending router commands
+#
+proc icepick_c_router {jrc rw block register payload} {
+
+ set new_dr_value \
+ [expr ( ($rw & 0x1) << 31)| ( ($block & 0x7) << 28) | \
+ ( ($register & 0xF) << 24) | ( $payload & 0xFF ) ]
+
+# echo "\tNew router value:\t0x[format %x $new_dr_value]"
+
+ # select router
+ irscan $jrc [CONST IR_ROUTER] -endstate IRPAUSE
+
+ # ROUTER instructions are 32 bits wide
+ set old_dr_value [drscan $jrc 32 $new_dr_value -endstate DRPAUSE]
+}
+
+# Configure the icepick control register
+proc icepick_c_setup {jrc} {
+
+ # send a router write, block is 0, register is 1, value is 0x2100
+ icepick_c_router $jrc 1 0x0 0x1 0x001000
+}
# jrc == TAP name for the ICEpick
# port == a port number, 0..15
proc icepick_c_tapenable {jrc port} {
+ # First CONNECT to the ICEPick
+# echo "Connecting to ICEPick"
+ icepick_c_connect $jrc
+
+# echo "Configuring the ICEpick"
+ icepick_c_setup $jrc
+
# NOTE: it's important not to enter RUN/IDLE state until
# done sending these instructions and data to the ICEpick.
# And never to enter RESET, which will disable the TAPs.
- # select router
- irscan $jrc 7 -endstate IRPAUSE
- drscan $jrc 8 0x89 -endstate DRPAUSE
+ # first enable power and clock for TAP
+ icepick_c_router $jrc 1 0x2 $port 0x100048
- # set ip control
- irscan $jrc 2 -endstate IRPAUSE
- drscan $jrc 32 [expr 0xa0002108 + ($port << 24)] -endstate DRPAUSE
+ # TRM states that the register should be read back here, skipped for now
- irscan $jrc 0x3F -endstate RUN/IDLE
+ # enable debug "default" mode
+ icepick_c_router $jrc 1 0x2 $port 0x102048
+
+ # TRM states that debug enable and debug mode should be read back and
+ # confirmed - skipped for now
+
+ # Finally select the tap
+ icepick_c_router $jrc 1 0x2 $port 0x102148
+
+ # Enter the bypass state
+ irscan $jrc [CONST IR_BYPASS] -endstate RUN/IDLE
runtest 10
}
+
+# This function uses the ICEPick to send a warm system reset
+proc icepick_c_wreset {jrc} {
+
+ # send a router write, block is 0, register is 1, value is 0x2100
+ icepick_c_router $jrc 1 0x0 0x1 0x002101
+}
+
+
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading application from GDB over APB (DAP AP 1)
On 09/28/2011 03:08 AM, Karl Kurbjun wrote:
Hi all,
I have an A9 target where the memory map visible over the AHB versus
what is visible to the processor is slightly different.
On this target the lower 512 kByte block of DDR is not accessible from
the AHB, but the processor is able to see it through the L2
controller. In order to access this memory I can tell OpenOCD to use
the APB DAP port ("dap apsel 1") thanks to Luca's work. With that I
am able to read and write to the memory without trouble within OpenOCD.
While it works within OpenOCD, I run into problems when I try to
connect and start debugging with GDB. I cannot load the application
through GDB without getting messages like the following:
"Ignoring packet error, continuing..."
after loading if I try to set a breakpoint ("b main") I get the
following message:
"Reply contains invalid hex digit 79"
To make sure that this was not a target specific issue I also verified
that this fails on the Pandaboard as well. I attached a -d3 log from
openocd when trying this out on the Pandaboard.
If I do not modify the AP used by the DAP (leave it to use the AHB)
prior to trying to load the application in GDB on the Pandaboard
everything works fine.
Does anyone have any suggestions on what might be causing this failure
while using the APB interface?
Thanks,
Karl
Sorry for the second email right in a row, but I forgot to include an
important piece which may point to the root cause. In order to
reproduce this failure I set the JTAG adapter speed down to 10 kHz on
the Pandaboard. If I set the adapter speed to 1MHz I do not see the
problem.
Looking at the logs it appears that this may be caused by gdb not seeing
a keep_alive packet, but I am not sure where a keep_alive is missing
from the code. It appears that OpenOCD is sending the packets often
enough when the speed is high enough and the DAP AP is the AHB, but the
combination of the slow cable speed and using the APB appears to cause a
timeout.
-Karl
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting rid of default jtag clock rate
On Mon, Dec 6, 2010 at 12:33 PM, Øyvind Harboe wrote: > I believe that there might exist a safe default or autodetection > scheme for a specific family of parts. > > Such parts could use a common configuration file which > did the autodetect/set the robust default frequency. > > The responsibility for deciding how to deal with JTAG clk > is still firmly in the board configuration file though. The > board config file might ultimately decide directly or > indirectly to use a family-default or autodetect scheme, > that was a decision made by the board config file. > > -- > Øyvind Harboe > > Can Zylin Consulting help on your project? > > US toll free 1-866-980-3434 / International +47 51 63 25 00 > > 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 > All device vendors should provide BSDL files for their devices which specify the maximum TCK speed the device can support. This can be used to create an auto-configuration that is fairly easy to use and robust. An example of this is the Xilinx programming tools. They do an initial shift at a low speed to find the JTAG ID's of each device. Once the device IDs are found a search is done against the BSDL files to find a matching description. Once that is complete the lowest maximum JTAG speed is used as an initial configuration based on the BSDL information. As an added benefit the JTAG instruction lengths are also defined in the BSDL so it does not need to be configured manually. If you see failures then you have the option of manually lowering the maximum JTAG frequency which overrides the BSDL files. -Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] iMX51 workaround
On Tue, Nov 30, 2010 at 12:18 AM, Øyvind Harboe wrote: > If iMX51 is broken and the current CortexA8 workaround code for it > breaks other CPUs, then I think that the automatic workaround code > for iMX51 has to be either fixed or removed. > > Thoughts? > > -- > Øyvind Harboe > > Can Zylin Consulting help on your project? > > US toll free 1-866-980-3434 / International +47 51 63 25 00 > > 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 > I agree that if a clean fix cannot be implemented and tested then it should be removed. One option might be to pull out the JTAG ID code along with the rest of the identifying factors to try and make the scenario even more unique, but I do not have a way to verify that it will work on the IMX51. The only thought I have from what I have seen of the code is to call "dap_queue_idcode_read" and include that value in the table of identifying factors, but I am not sure if that will work on the problem target or if it is alright to do in this section of the code. -Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Fwd: [beagleboard] Flyswatter with XM]
On Wed, Nov 24, 2010 at 10:32 PM, Antonio Borneo wrote: > Jon, > this issue has already been reported by Karl in > https://lists.berlios.de/pipermail/openocd-development/2010-November/017056.html > > the issue is linked with patch in > https://lists.berlios.de/pipermail/openocd-development/2010-November/016854.html > > Best Regards > Antonio Borneo > > On Thu, Nov 25, 2010 at 1:10 PM, Jon Masters wrote: >> Hello, >> >> Anyone here have suggestions? >> >> Thanks! >> >> Jon. >> >> >> >> -- Forwarded message -- >> From: Jon Masters >> To: beagleboard >> Date: Wed, 24 Nov 2010 23:59:20 -0500 >> Subject: [beagleboard] Flyswatter with XM >> Hello, >> >> Has anyone managed to get the TinCanTools Flyswatter working with the >> XM? I did with the original Beagle, but upstream OCD does this with XM: >> >> [...@constitution openocd]$ sudo /usr/local/bin/openocd >> -s /usr/local/lib/openocd >> -f /usr/local/share/openocd/scripts/interface/flyswatter.cfg >> -f /usr/local/share/openocd/scripts/board/ti_beagleboard_xm.cfg >> Open On-Chip Debugger 0.5.0-dev-00620-g1892a2b (2010-11-24-13:01) >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.berlios.de/doc/doxygen/bugs.html >> Info : only one transport option; autoselect 'jtag' >> 10 kHz >> Warn : dm37x.dsp: huge IR length 38 >> trst_only separate trst_push_pull >> Info : clock speed 10 kHz >> Info : JTAG tap: dm37x.jrc tap/device found: 0x0b89102f (mfg: 0x017, >> part: 0xb891, ver: 0x0) >> Info : JTAG tap: dm37x.dap enabled >> Warn : Found broken CPU (imx51), trying to fixup ROM Table location from >> 0x8000 to 0x6000 >> Error: JTAG-DP STICKY ERROR >> Error: MEM_AP_CSW 0x8042, MEM_AP_TAR 0x6000 >> Polling target failed, GDB will be halted. Polling again in 100ms >> Polling target failed, GDB will be halted. Polling again in 300ms >> Polling target failed, GDB will be halted. Polling again in 700ms >> Polling target failed, GDB will be halted. Polling again in 1500ms >> Polling target failed, GDB will be halted. Polling again in 3100ms >> Polling target failed, GDB will be halted. Polling again in 6300ms >> etc. >> >> I haven't had chance to look at the code yet, but I think some of the >> broken CPU detection/fixup stuff has changed recently. Still, the >> warning about the IMX51 is concerning. What ROM table is it referring to >> exactly? Is this something on the Flyswatter board? Does anyone happen >> to know these things before I go digging? (I used to use BDI2000s but >> they're a little expensive for home...not a huge OCD user yet). >> >> Jon. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Beagle Board" group. >> To post to this group, send email to beaglebo...@googlegroups.com. >> To unsubscribe from this group, send email to >> beagleboard+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/beagleboard?hl=en. >> >> >> >> ___ >> 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 > John, I use the Tin-Can Tools Flyswatter for my debugging. It works fine, but the IMX51 patch broke debugging. If you just comment out that for loop in the email Antonio linked it will work fine. I have some additional TCL script modifications I have done to make the debugging a bit more robust that I can post sometime after this coming weekend. >From the reading I have done I think the only reliable way to identify the device is with the JTAG ID code, but I am not sure what the best way is to access that in the cortex_a8.c file. -Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic detection of debugbase for cortex A8
On Sat, Nov 6, 2010 at 8:42 AM, Øyvind Harboe wrote:
> I've merged Marek's work:
>
> http://repo.or.cz/w/openocd/cortex.git
>
> I'm pleased not only with the result, but how the set of patches
> came about through a great discussion on the list and
> improvement of Marek's original solution!
>
> (I haven't actually been able to try it, though it looks great
> to me, and it is reported as working.)
>
> --
> Øyvind Harboe
>
> Can Zylin Consulting help on your project?
>
> US toll free 1-866-980-3434 / International +47 51 63 25 00
>
> 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
>
This patch breaks debugging on the DM37x. It appears that the debug
base and APID is not sufficient to identify problematic processors
since the DM37x on the Beagleboard XM incorrectly passes the checks in
arm_adi_v5.c:
for (i = 0; i < sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
if (broken_cpus[i].dbgbase == dbgbase &&
broken_cpus[i].apid == apid) {
LOG_WARNING("Found broken CPU (%s), trying to fixup "
"ROM Table location from 0x%08x to 0x%08x",
broken_cpus[i].model, dbgbase,
broken_cpus[i].correct_dbgbase);
dbgbase = broken_cpus[i].correct_dbgbase;
break;
}
Is there another way that these problematic CPUs can be identified?
-Karl
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] omap3530 problem: ICEPick found, but armcore not found
On 11/09/2010 06:37 PM, David Brownell wrote: --- On Tue, 11/9/10, 韦东山 wrote: From: 韦东山 Yes, it can't enable the Cortex core. I delete this line in the cofigration file: " jtag configure $_CHIPNAME.jrc -event setup "jtag tapenable $_CHIPNAME.dap" " and run "jtag tapenable omap3530.dap" in the telnet windows, the output is the same: And after you broke the configuration, you were for some reason surprised that it didn't work I don't recall specifically what I did to bring up a Beagle last time, "reset init" was about the level of complexity required, though. A routine operation to kick off the various events which bring up the CPU via ICEPick and other ops. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development 韦东山, When I was setting up the beagleboard XM I was getting those sticky messages also. I am not sure of their significance, but you can still debug after seeing those. As David Said, you should just have to do a reset which will indirectly run "omap3_dbginit" to debug the MPU (Cortex A8). "omap3_dbginit" is the function you need to call either direct, or indirect (with reset). This enables invasive debugging and will allow you to set breakpoints and halt the processor among other things. If you would like to setup invasive debugging without resetting the processor just run "omap3_dbginit omap3530.cpu". One thing to note: Older revisions of the openocd tools did not have "mww phys" in the dbginit for the omap3530 configuration scripts. If you have an older revision you might want to check out the latest since that has been fixed. The last line of "omap_dbginit" in omap3530.cfg should read as follows: $target mww phys 0x5401d030 0x2000 There is another ARM processor in the device which is part of the IVA. If you are trying to debug that you will need to modify the configuration files. I am not sure what exactly you would need to do offhand since I have not worked on debugging that processor. -Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cortex A8 Watchpoints
Hi all,
I am trying to use watchpoints with the A8, but they do not appear to be
working. I have some simple test code that demonstrates this:
---
void main()
{
while(1)
{
test_data++;
delay_count = 5;
while(delay_count--) {};
}
}
---
I tried to set a watchpoint on test_data (a global variable) with gdb:
---
0x00016f64 in ?? ()
(gdb) load
Loading section .boot_header, size 0x20 lma 0x4020
Loading section .vectors, size 0x20 lma 0x40200020
Loading section .init, size 0xf0 lma 0x40200040
Loading section .bob, size 0x374 lma 0x40200130
Loading section .data, size 0x4 lma 0x402004a4
Start address 0x40200020, load size 1192
Transfer rate: 7 KB/sec, 238 bytes/write.
(gdb) awatch test_data
Hardware access (read/write) watchpoint 1: test_data
(gdb) cont
Continuing.
^C
(gdb) info watchpoints
Num Type Disp Enb AddressWhat
1 acc watchpoint keep y test_data
---
but the processor never stops.
I double checked the objdump of the code:
---
402004a4 :
402004a4:0002 andeqr0, r0, r2
---
I then tried to set a watchpoint direct in OpenOCD and it appears to work:
---
> wp 0x402004a4 4
> resume
target state: halted
target halted in ARM state due to watchpoint, current mode: Supervisor
cpsr: 0x61d3 pc: 0x4020043c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Watchpoint triggered at PC 0x4020043c
---
Is this a known issue with watchpoints within GDB or am I doing
something wrong?
-Karl
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Skip halt check in cortex_a8_mmu
I have been able to run a similar function on the DM37x without halting
the processor. The DM37x is very similar to the OMAP. One thing I
noticed is that the write did not work when the processor was halted
unless I called "mww phys" to set DBGEN. For some reason just "mww" was
failing even if the MMU was not enabled.
Have you tried using a physical address write?
-Karl
On 09/24/2010 04:36 PM, Zachary T Welch wrote:
Without this patch, omap3_dbginit's attempt to set DBGEN will fail
when the CPU is running, and the debugger cannot halt the CPU without
that bit set. This patch does not need to be committed as-is; rather,
I want to know: how is it that no one else reported this issue?
What negative consequences can result from removing this check?
---
src/target/cortex_a8.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 8b4ced5..9e09ddb 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -2014,11 +2014,6 @@ static int cortex_a8_enable_mmu_caches(struct target
*target, int mmu,
static int cortex_a8_mmu(struct target *target, int *enabled)
{
- if (target->state != TARGET_HALTED) {
- LOG_ERROR("%s: target not halted", __func__);
- return ERROR_TARGET_INVALID;
- }
-
*enabled =
target_to_cortex_a8(target)->armv7a_common.armv4_5_mmu.mmu_enabled;
return ERROR_OK;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Status of Cortex-A8 Support?
On 09/17/2010 03:08 PM, David Brownell wrote: Presently, I would like to hear about the perceived status> of Cortex-A8, It gets through OMAP3 bringup. The ROM table scanning embeds various assumptions; see the comments in the ARM ADI_V5.c file. I'm not sure whether it's good to assume DAP 0 is used, as one of the examples, of which MEM-AP to use. The MX51 is a bit different than OMAP. I don't know about other chips using A8 cores... or, A9. as one of my initial goals will be to "validate" that support. If you are using OpenOCD on a Cortex-A8 platform, what problems do you face? What features still need work? And contributors of this support: are there any horrible blemishes remaining in this code? I've tried to leave comments in the code re any open issues I observed. Historically, the A8 code evolved from the M3 code, at least for the ROM table scanning (not debug). The v7a (Cortex-A) debug support is ISTR not all there, but it's not too bad. ARM did good things by having v6 and v7a use the same model (DPM), so what OpenOCD needs to do is jut fill in various missing bits. Again, read code comments. Also, cross-check against the ARM-v7AR TRM. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Hi Zach and David, I have been using OpenOCD for some basic debug work on the Beagleboard xM which is a TI DM37x (similar to the OMAP3). I can run simple programs and single step them inside OpenOCD and GDB. I have not tried significant debugging with an application that uses the MMU yet. There are some minor issues I have seen that do not appear to effect my ability to debug, but are odd. For example when I initially connect to the target I get a bunch of errors similar to the following: $ ./openocd -f interface/flyswatter.cfg -f board/ti_beagleboard_xm.cfg Open On-Chip Debugger 0.5.0-dev-00500-g35af12d (2010-09-06-14:01) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 10 kHz Warn : dm37x.dsp: huge IR length 38 trst_only separate trst_push_pull Info : device: 4 "2232C" Info : deviceID: 67330064 Info : SerialNumber: FS00 A Info : Description: Flyswatter A Info : clock speed 10 kHz Info : JTAG tap: dm37x.jrc tap/device found: 0x0b89102f (mfg: 0x017, part: 0xb891, ver: 0x0) Info : JTAG tap: dm37x.dap enabled Info : dm37x.cpu: hardware has 6 breakpoints, 2 watchpoints Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0 To test some basic debug operations inside OpenOCD with the MMU I let the Linux demonstration load up. It appears that virtual to physical memory translation works. If I single step it gives a message that there was a timeout waiting for halt: Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > amdm37x_dbginit dm37x.cpu > halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x6093 pc: 0xc003cf8c MMU: enabled, D-Cache: enabled, I-Cache: enabled > virt2phys 0xc003cf8c Physical address 0x8003cf8c > step target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x6093 pc: 0xc003cf90 MMU: enabled, D-Cache: enabled, I-Cache: enabled timeout waiting for target halt Command handler execution failed in procedure 'step' As I mentioned earlier though if I run simple software designs that do not use the MMU I can set breakpoints inside GDB, run to them and examine variables along with memory just fine. I have not noticed any oddities single stepping in those applications. -Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] AM/DM37x: Unify configuration files and add support for TI Beagleboard xM
On 09/18/2010 09:43 AM, Karl Kurbjun wrote:
Hi everyone,
I have included a patch to add support for the DM37x by creating a
unified configuration with the AM35x initial support that was added
with the AM3517evm board configuration file. I added copyrights to
the unified file from what I could gather from the git logs of the
people that were involved at one point (omap3530.cfg and am3517evm.cfg).
This patch also adds support for the TI Beagleboard xM.
Let me know if you would like anything corrected.
-Karl
Update:
I left out one change that prevented the Beagleboard xM board
configuration from working. Here is the updated patch. Also as a note:
I have not tried this on the AM3517evm since I do not have the board.
If someone has it and can try this patch it would be appreciated.
-Karl
>From 0a3da3b956b7e320c1ca09069c4c9a48090b7d2f Mon Sep 17 00:00:00 2001
From: Karl Kurbjun
Date: Sat, 18 Sep 2010 09:55:29 -0600
Subject: [PATCH] AM/DM37x: Unify configuration scripts and add support for TI Beagleboard xM.
---
tcl/board/am3517evm.cfg | 88 +
tcl/board/ti_beagleboard_xm.cfg | 12 +++
tcl/target/amdm37x.cfg | 203 +++
3 files changed, 221 insertions(+), 82 deletions(-)
create mode 100644 tcl/board/ti_beagleboard_xm.cfg
create mode 100644 tcl/target/amdm37x.cfg
diff --git a/tcl/board/am3517evm.cfg b/tcl/board/am3517evm.cfg
index db76255..2bff512 100644
--- a/tcl/board/am3517evm.cfg
+++ b/tcl/board/am3517evm.cfg
@@ -10,88 +10,12 @@
# http://processors.wiki.ti.com/index.php/Debug_Access_Port_(DAP)
# http://processors.wiki.ti.com/index.php?title=How_to_Find_the_Silicon_Revision_of_your_OMAP35x
-# Slooow during startup
-adapter_khz 10
+set CHIPTYPE "am35x"
+source [find target/amdm37x.cfg]
+# The TI-14 JTAG connector does not have srst. CPU reset is handled in
+# hardware.
+reset_config trst_only
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME am3517
-}
-
-set JRC_TAPID 0
-
-set DAP_TAPID 0x0b86802f
-
-# Subsidiary TAP: CoreSight Debug Access Port (DAP)
-if { [info exists DAP_TAPID ] } {
- set _DAP_TAPID $DAP_TAPID
-} else {
- set _DAP_TAPID 0x0b6d602f
-}
-
-
-# Primary TAP: ICEpick-C (JTAG route controller) and boundary scan
-if { [info exists JRC_TAPID ] } {
- set _JRC_TAPID $JRC_TAPID
-} else {
- set _JRC_TAPID 0x0b7ae02f
-}
-
-# ICEpick-C ... used to route Cortex, and more not shown here
-source [find target/icepick.cfg]
-
-
-jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0xf \
- -expected-id $_DAP_TAPID -disable
-jtag configure $_CHIPNAME.dap -event tap-enable \
- "icepick_c_tapenable $_CHIPNAME.jrc 3"
-
-jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f \
- -expected-id $_JRC_TAPID
-
-
-
-# GDB target: Cortex-A8, using DAP
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
-
-# SRAM: 64K at 0x4020.; use the first 16K
-$_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
-
-###
-
-# the reset sequence is event-driven
-# and kind of finicky...
-
-# some TCK tycles are required to activate the DEBUG power domain
-jtag configure $_CHIPNAME.jrc -event post-reset "runtest 100"
-
-# have the DAP "always" be active
-jtag configure $_CHIPNAME.jrc -event setup "jtag tapenable $_CHIPNAME.dap"
-
-proc omap3_dbginit {target} {
-
- # General Cortex A8 debug initialisation
- cortex_a8 dbginit
- # Enable DBGU signal for OMAP353x
- $target mww phys 0x5401d030 0x2000
-}
-
-# be absolutely certain the JTAG clock will work with the worst-case
-# 16.8MHz/2 = 8.4MHz core clock, even before a bootloader kicks in.
-# OK to speed up *after* PLL and clock tree setup.
-
-$_TARGETNAME configure -event "reset-start" { adapter_khz 10}
-
-# Assume SRST is unavailable (e.g. TI-14 JTAG), so we must assert reset
-# ourselves using PRM_RSTCTRL. RST_GS (2) is a warm reset, like ICEpick
-# would issue. RST_DPLL3 (4) is a cold reset.
-set PRM_RSTCTRL 0x48307250
-$_TARGETNAME configure -event reset-assert "$_TARGETNAME mww phys $PRM_RSTCTRL 2"
-
-$_TARGETNAME configure -event reset-assert-post "omap3_dbginit $_TARGETNAME; adapter_khz 1000"
-
+# "amdm37x_dbginit am35x.cpu" needs to be run after init.
-reset_config trst_only
diff --git a/tcl/board/ti_beagleboard_xm.cfg b/tcl/board/ti_beagleboard_xm.cfg
new file mode 100644
index 000..e4e93e3
--- /dev/null
+++ b/tcl/board/ti_beagleboard_xm.cfg
@@ -0,0 +1,12 @@
+# BeagleBoard xM (DM37x)
+# http://beagleboard.org
+
+set CHIPTYPE "dm37x"
+source [find target/amdm37x.cfg]
+
+# The TI-14 JTAG connector does not have srst. CPU reset is handled in
+# hardware.
+reset_config trst_only
+
+# "amdm37x_dbginit dm37x.cpu" needs to be run after init.
+
diff --git a/tcl/target/amdm37x.cfg b/tcl/target/
[Openocd-development] [PATCH] AM/DM37x: Unify configuration files and add support for TI Beagleboard xM
Hi everyone,
I have included a patch to add support for the DM37x by creating a
unified configuration with the AM35x initial support that was added with
the AM3517evm board configuration file. I added copyrights to the
unified file from what I could gather from the git logs of the people
that were involved at one point (omap3530.cfg and am3517evm.cfg).
This patch also adds support for the TI Beagleboard xM.
Let me know if you would like anything corrected.
-Karl
>From 1908b27c19905a18a9fa6111694a4df7271b8eef Mon Sep 17 00:00:00 2001
From: Karl Kurbjun
Date: Sat, 18 Sep 2010 09:33:45 -0600
Subject: [PATCH] AM/DM37x: Unify configuration scripts and add support for TI Beagleboard xM.
---
tcl/board/am3517evm.cfg | 88 +
tcl/board/ti_beagleboard_xm.cfg | 12 +++
tcl/target/amdm37x.cfg | 203 +++
3 files changed, 221 insertions(+), 82 deletions(-)
create mode 100644 tcl/board/ti_beagleboard_xm.cfg
create mode 100644 tcl/target/amdm37x.cfg
diff --git a/tcl/board/am3517evm.cfg b/tcl/board/am3517evm.cfg
index db76255..2bff512 100644
--- a/tcl/board/am3517evm.cfg
+++ b/tcl/board/am3517evm.cfg
@@ -10,88 +10,12 @@
# http://processors.wiki.ti.com/index.php/Debug_Access_Port_(DAP)
# http://processors.wiki.ti.com/index.php?title=How_to_Find_the_Silicon_Revision_of_your_OMAP35x
-# Slooow during startup
-adapter_khz 10
+set CHIPTYPE "am35x"
+source [find target/amdm37x.cfg]
+# The TI-14 JTAG connector does not have srst. CPU reset is handled in
+# hardware.
+reset_config trst_only
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME am3517
-}
-
-set JRC_TAPID 0
-
-set DAP_TAPID 0x0b86802f
-
-# Subsidiary TAP: CoreSight Debug Access Port (DAP)
-if { [info exists DAP_TAPID ] } {
- set _DAP_TAPID $DAP_TAPID
-} else {
- set _DAP_TAPID 0x0b6d602f
-}
-
-
-# Primary TAP: ICEpick-C (JTAG route controller) and boundary scan
-if { [info exists JRC_TAPID ] } {
- set _JRC_TAPID $JRC_TAPID
-} else {
- set _JRC_TAPID 0x0b7ae02f
-}
-
-# ICEpick-C ... used to route Cortex, and more not shown here
-source [find target/icepick.cfg]
-
-
-jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0xf \
- -expected-id $_DAP_TAPID -disable
-jtag configure $_CHIPNAME.dap -event tap-enable \
- "icepick_c_tapenable $_CHIPNAME.jrc 3"
-
-jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f \
- -expected-id $_JRC_TAPID
-
-
-
-# GDB target: Cortex-A8, using DAP
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
-
-# SRAM: 64K at 0x4020.; use the first 16K
-$_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
-
-###
-
-# the reset sequence is event-driven
-# and kind of finicky...
-
-# some TCK tycles are required to activate the DEBUG power domain
-jtag configure $_CHIPNAME.jrc -event post-reset "runtest 100"
-
-# have the DAP "always" be active
-jtag configure $_CHIPNAME.jrc -event setup "jtag tapenable $_CHIPNAME.dap"
-
-proc omap3_dbginit {target} {
-
- # General Cortex A8 debug initialisation
- cortex_a8 dbginit
- # Enable DBGU signal for OMAP353x
- $target mww phys 0x5401d030 0x2000
-}
-
-# be absolutely certain the JTAG clock will work with the worst-case
-# 16.8MHz/2 = 8.4MHz core clock, even before a bootloader kicks in.
-# OK to speed up *after* PLL and clock tree setup.
-
-$_TARGETNAME configure -event "reset-start" { adapter_khz 10}
-
-# Assume SRST is unavailable (e.g. TI-14 JTAG), so we must assert reset
-# ourselves using PRM_RSTCTRL. RST_GS (2) is a warm reset, like ICEpick
-# would issue. RST_DPLL3 (4) is a cold reset.
-set PRM_RSTCTRL 0x48307250
-$_TARGETNAME configure -event reset-assert "$_TARGETNAME mww phys $PRM_RSTCTRL 2"
-
-$_TARGETNAME configure -event reset-assert-post "omap3_dbginit $_TARGETNAME; adapter_khz 1000"
-
+# "amdm37x_dbginit am35x.cpu" needs to be run after init.
-reset_config trst_only
diff --git a/tcl/board/ti_beagleboard_xm.cfg b/tcl/board/ti_beagleboard_xm.cfg
new file mode 100644
index 000..5ee8bb1
--- /dev/null
+++ b/tcl/board/ti_beagleboard_xm.cfg
@@ -0,0 +1,12 @@
+# BeagleBoard xM (DM37x)
+# http://beagleboard.org
+
+set CHIPNAME "dm37x"
+source [find target/amdm37x.cfg]
+
+# The TI-14 JTAG connector does not have srst. CPU reset is handled in
+# hardware.
+reset_config trst_only
+
+# "amdm37x_dbginit dm37x.cpu" needs to be run after init.
+
diff --git a/tcl/target/amdm37x.cfg b/tcl/target/amdm37x.cfg
new file mode 100644
index 000..ab18681
--- /dev/null
+++ b/tcl/target/amdm37x.cfg
@@ -0,0 +1,203 @@
+#
+# Copyright (C) 2010by Karl Kurbjun
+# Copyright (C) 2009, 2010 by Ãyvind Harboe
+# Copyright (C) 2009by David Brownell
+# Copyright (C) 2009by Magnus Lundin
+#
+# TI AM/DM37x
+# http
[Openocd-development] [PATCH] Fujitsu MBM29SL800TE flash support
Hi,
This is my first post to the list. First, I would like to thank
everyone for their work on OpenOCD, it is a great tool to work with. I
have been using it to debug code on hardware for the Rockbox project
(www.rockbox.org).
The target that I primarily work with has a Spansion/Fujitsu NOR flash
(MBM29SL800TE). I attached a patch that adds support for this flash. I
hope it can be included in the main repository. If there is something
that needs to be changed with the patch before inclusion please let me
know.
-Karl Kurbjun
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index 4ef41b9..cbb3bb0 100644
--- a/src/flash/nor/cfi.c
+++ b/src/flash/nor/cfi.c
@@ -57,6 +57,7 @@ static const struct cfi_fixup cfi_0002_fixups[] = {
{CFI_MFR_SST, 0x00D7, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_SST, 0x2780, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_ATMEL, 0x00C8, cfi_fixup_atmel_reversed_erase_regions, NULL},
+ {CFI_MFR_FUJITSU, 0x22ea, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
{CFI_MFR_FUJITSU, 0x226b, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_AMIC, 0xb31a, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
{CFI_MFR_MX, 0x225b, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
diff --git a/src/flash/nor/non_cfi.c b/src/flash/nor/non_cfi.c
index b49e441..e0ea568 100644
--- a/src/flash/nor/non_cfi.c
+++ b/src/flash/nor/non_cfi.c
@@ -280,6 +280,23 @@ static struct non_cfi non_cfi_flashes[] = {
ERASE_REGION(15, 64*KB)
}
},
+ {
+ .mfr = CFI_MFR_FUJITSU,
+ .id = 0x22ea,/* MBM29SL800TE */
+ .pri_id = 0x02,
+ .dev_size = 1*MB,
+ .interface_desc = 0x2, /* x8 or x16 device with nBYTE */
+ .max_buf_write_size = 0x0,
+ .status_poll_mask = CFI_STATUS_POLL_MASK_DQ5_DQ6_DQ7,
+ .num_erase_regions = 4,
+ .erase_region_info =
+ {
+ ERASE_REGION(15, 64*KB),
+ ERASE_REGION(1, 32*KB),
+ ERASE_REGION(2, 8*KB),
+ ERASE_REGION(1, 16*KB)
+ }
+ },
{
.mfr = CFI_MFR_FUJITSU,
.id = 0xba,/* 29LV400BC */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
