Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Marek Vasut wrote: So it turns out (by reading Freescale iMX515 errata), ENGcm09395 to be exact Please mention this within the fixup function. But that being the case, I'd prefer to make an incremental patch on top of the patches I submitted. Please don't, since some of the former patches were going in the wrong direction. I think the new patches look really good, but please fix them to apply on git master rather than your previous ones. Thanks! //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
I think caring about the variant should strongly be avoided. Use the ROM table by default. Only in the case of a broken ROM table should we (a) emit a message, then (b) work around the brokenness. Such working-around might care about variant, if wecan't come up with a simple heuristic fix. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Sun, Oct 31, 2010 at 10:59 AM, David Brownell davi...@pacbell.net wrote: I think caring about the variant should strongly be avoided. Use the ROM table by default. Only in the case of a broken ROM table should we (a) emit a message, then (b) work around the brokenness. Such working-around might care about variant, if wecan't come up with a simple heuristic fix. It would be great if we could detect the one broken chip out there and simply add a workaround(with warning). I'd suppose such bugs would be much less common with more recent Cortex A8 chips. Adding options is the last resort as it makes OpenOCD harder to use and gives it a more unfinished feeling. This is open source. If there is a chance that we might need to add support for a new CPU in the future, then we don't add some option in the hope that it can work around the next bug, we just add the workaround when and if that time comes. -- Øyvind Harboe 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
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Sunday 31 October 2010 13:16:43 Øyvind Harboe wrote: On Sun, Oct 31, 2010 at 10:59 AM, David Brownell davi...@pacbell.net wrote: I think caring about the variant should strongly be avoided. Use the ROM table by default. Only in the case of a broken ROM table should we (a) emit a message, then (b) work around the brokenness. Such working-around might care about variant, if wecan't come up with a simple heuristic fix. Would you mind not dropping me from the CC ? Thanks It would be great if we could detect the one broken chip out there and simply add a workaround(with warning). Implemented in V2, which should have just landed in the mailing list ... Peter, David, sorry for not CCing you, next time, you'll be there (well, I hope there will be no next time and that the patches are good :) ). I'd suppose such bugs would be much less common with more recent Cortex A8 chips. I hope so as well Adding options is the last resort as it makes OpenOCD harder to use and gives it a more unfinished feeling. This is open source. If there is a chance that we might need to add support for a new CPU in the future, then we don't add some option in the hope that it can work around the next bug, we just add the workaround when and if that time comes. So can you please check the V2s ? Thanks ! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Saturday 30 October 2010 07:24:08 Marek Vasut wrote: On Friday 29 October 2010 09:37:36 Øyvind Harboe wrote: Oyvind sorry, I just can't find it ... could you tell me where it is please ? Start here: https://lists.berlios.de/pipermail/openocd-development/2010-September/016 48 2.html Hey, I went through all of this stuff tonight ... and I came to a conclusion, that MEM-AP contains register called BASE whose top 20 bytes should contain the debug base address. From my observation, if I run: dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x8000 ROM table in legacy format CID3 0x00, CID2 0x00, CID1 0x00, CID0 0x00 MEMTYPE System memory not present. Dedicated debug bus. ROMTABLE[0x0] = 0x0 End of ROM table I get no data. Though if I artificially adjust the dbgbase to 0x6000 in arm_adi_v5.c, I get the following stuff. So, is the processor just making fun of me and misreporting the debug base or did I just miss something? This is what I get after the adjustment dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x6000 ROM table in legacy format CID3 0xb1, CID2 0x05, CID1 0x10, CID0 0x0d MEMTYPE System memory not present. Dedicated debug bus. --SNIP-- So it turns out (by reading Freescale iMX515 errata), ENGcm09395 to be exact that the chip misreports the ROM Table address (it reports 0x8000_, but it should report 0x6000_). On the other hand, the contents of the ROM Table is then correct. Oyvind, this technically makes the autodetection complementary to manual approach. There is a solution I see now -- implement the autodetection, which will work on most chips (modulo iMX515 ...) and add an option to manually specify the ROM Table base. But that being the case, I'd prefer to make an incremental patch on top of the patches I submitted. Cheers ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: Shouldn't this be automatically detected? yes it should ... i'll send a patch on top of this one once I figure out how to do it. Is that good enough approach for you? Or shall we put these on hold until then? I would definitely like the autodetect to go in first, then the patches can be simplified. -- Øyvind Harboe 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
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: Shouldn't this be automatically detected? yes it should ... i'll send a patch on top of this one once I figure out how to do it. Is that good enough approach for you? Or shall we put these on hold until then? I would definitely like the autodetect to go in first, then the patches can be simplified. You've got a point here, but I really don't know how much time will that take, though I'll look into it probably even today. I'd appreciate any hints on this. Zach made some postings in the not to distant path to the list about this subject. -- Øyvind Harboe 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
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Friday 29 October 2010 07:43:18 Peter Stuge wrote: Marek Vasut wrote: In this patch, I introduce the use of -variant parameter, so I can adjust the debug_base accordingly. This seems completely wrong to me. I think this logic should just stay in Tcl. So if anything, you would add a parameter for dap_base. That's what I wanted to do, but I'm still starting to get familiar with OpenOCD again. Could you point me in a direction please? //Peter ___ 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] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Friday 29 October 2010 08:18:46 Marek Vasut wrote: On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: Shouldn't this be automatically detected? yes it should ... i'll send a patch on top of this one once I figure out how to do it. Is that good enough approach for you? Or shall we put these on hold until then? I would definitely like the autodetect to go in first, then the patches can be simplified. You've got a point here, but I really don't know how much time will that take, though I'll look into it probably even today. I'd appreciate any hints on this. Zach made some postings in the not to distant path to the list about this subject. thanks! i'll look once I arive at university ... I just left dorms and I'm going for a bus :b Oyvind sorry, I just can't find it ... could you tell me where it is please ? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Fri, Oct 29, 2010 at 9:33 AM, Marek Vasut marek.va...@gmail.com wrote: On Friday 29 October 2010 07:43:18 Peter Stuge wrote: Marek Vasut wrote: In this patch, I introduce the use of -variant parameter, so I can adjust the debug_base accordingly. This seems completely wrong to me. I think this logic should just stay in Tcl. So if anything, you would add a parameter for dap_base. That's what I wanted to do, but I'm still starting to get familiar with OpenOCD again. Could you point me in a direction please? This should be picked up automatically, so this is the wrong direction. If you type dap info 0, I believe it prints out the debug base, so the code is even in there in OpenOCD. -- Øyvind Harboe 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
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Oyvind sorry, I just can't find it ... could you tell me where it is please ? Start here: https://lists.berlios.de/pipermail/openocd-development/2010-September/016482.html -- Øyvind Harboe 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
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base?according to variant
Marek Vasut wrote: add a parameter for dap_base. That's what I wanted to do, but I'm still starting to get familiar with OpenOCD again. Could you point me in a direction please? Um, well, don't you just do the same thing as you did for -variant, except use strtoul() in the C code? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Øyvind Harboe wrote: So if anything, you would add a parameter for dap_base. Could you point me in a direction please? This should be picked up automatically, so this is the wrong direction. If you type dap info 0, I believe it prints out the debug base, so the code is even in there in OpenOCD. Awesome! Sorry for my noise. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Friday 29 October 2010 09:37:36 Øyvind Harboe wrote: Oyvind sorry, I just can't find it ... could you tell me where it is please ? Start here: https://lists.berlios.de/pipermail/openocd-development/2010-September/01648 2.html Hey, I went through all of this stuff tonight ... and I came to a conclusion, that MEM-AP contains register called BASE whose top 20 bytes should contain the debug base address. From my observation, if I run: dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x8000 ROM table in legacy format CID3 0x00, CID2 0x00, CID1 0x00, CID0 0x00 MEMTYPE System memory not present. Dedicated debug bus. ROMTABLE[0x0] = 0x0 End of ROM table I get no data. Though if I artificially adjust the dbgbase to 0x6000 in arm_adi_v5.c, I get the following stuff. So, is the processor just making fun of me and misreporting the debug base or did I just miss something? This is what I get after the adjustment dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x6000 ROM table in legacy format CID3 0xb1, CID2 0x05, CID1 0x10, CID0 0x0d MEMTYPE System memory not present. Dedicated debug bus. ROMTABLE[0x0] = 0x1003 Component base address 0x60001000, start address 0x60001000 Component class is 0x9, CoreSight component Type is 0x21, Trace Sink, Buffer Peripheral ID[4..0] = hex 04 00 0b b9 07 Part is Coresight ETB (Trace Buffer) ROMTABLE[0x4] = 0x2003 Component base address 0x60002000, start address 0x60002000 Component class is 0x9, CoreSight component Type is 0x13, Trace Source, Processor Peripheral ID[4..0] = hex 04 10 4b b9 21 Part is Cortex-A8 ETM (Embedded Trace) ROMTABLE[0x8] = 0x3003 Component base address 0x60003000, start address 0x60003000 Component class is 0x9, CoreSight component Type is 0x11, Trace Sink, Port Peripheral ID[4..0] = hex 04 00 4b b9 12 Part is Coresight TPIU (Trace Port Interface Unit) ROMTABLE[0xc] = 0x4003 Component base address 0x60004000, start address 0x60004000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 10 4b b9 22 Part is Cortex-A8 CTI (Cross Trigger) ROMTABLE[0x10] = 0x5003 Component base address 0x60005000, start address 0x60005000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 00 0b b9 06 Part is Coresight CTI (Cross Trigger) ROMTABLE[0x14] = 0x6003 Component base address 0x60006000, start address 0x60006000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 00 0b b9 06 Part is Coresight CTI (Cross Trigger) ROMTABLE[0x18] = 0x7003 Component base address 0x60007000, start address 0x60007000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 00 0b b9 06 Part is Coresight CTI (Cross Trigger) ROMTABLE[0x1c] = 0x8003 Component base address 0x60008000, start address 0x60008000 Component class is 0x9, CoreSight component Type is 0x15, Debug Logic, Processor Peripheral ID[4..0] = hex 04 10 4b bc 08 Part is Cortex-A8 Debug (Debug Unit) ROMTABLE[0x20] = 0x0 End of ROM table ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
In this patch, I introduce the use of -variant parameter, so I can adjust the
debug_base accordingly.
So far, only the OMAP3530 and AM/DM37x CPUs, which utilize the Cortex A8 core
are supported by OpenOCD and both of these use the same Cortex A8 Debug Access
Port address (0x54011000).
There are other CPU manufacturers, who use different address for the Cortex A8
Debug Access Port though. As I was unable to figure out a way to detect the
address of DAP, this should at least work around the problem until there is a
proper solution.
Signed-off-by: Marek Vasut marek.va...@gmail.com
---
src/target/cortex_a8.c | 11 ++-
tcl/target/amdm37x.cfg |3 ++-
tcl/target/omap3530.cfg |3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 8b4ced5..64b78bd 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -1719,7 +1719,16 @@ static int cortex_a8_examine_first(struct target *target)
LOG_DEBUG(TODO - autoconfigure);
/* Here we shall insert a proper ROM Table scan */
- armv7a-debug_base = OMAP3530_DEBUG_BASE;
+ if (strcmp(target-variant, amdm37x) == 0)
+ armv7a-debug_base = OMAP3530_DEBUG_BASE;
+ else if (strcmp(target-variant, omap3530) == 0)
+ armv7a-debug_base = OMAP3530_DEBUG_BASE;
+ else {
+ LOG_DEBUG(Unknown CPU variant);
+ return ERROR_FAIL;
+ }
+
+ LOG_DEBUG(Using Cortex A8, %s variant, target-variant);
/* We do one extra read to ensure DAP is configured,
* we call ahbap_debugport_init(swjdp) instead
diff --git a/tcl/target/amdm37x.cfg b/tcl/target/amdm37x.cfg
index ab18681..3776435 100644
--- a/tcl/target/amdm37x.cfg
+++ b/tcl/target/amdm37x.cfg
@@ -142,7 +142,8 @@ jtag configure $_CHIPNAME.jrc -event setup jtag tapenable
$_CHIPNAME.dap
# Create the CPU target to be used with GDB: Cortex-A8, using DAP
set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap \
+ -variant amdm37x
# The DM37x has 64K of SRAM starting at address 0x4020_. Allow the first
# 16K to be used as a scratchpad for OpenOCD.
diff --git a/tcl/target/omap3530.cfg b/tcl/target/omap3530.cfg
index ba130a9..e7b598f 100644
--- a/tcl/target/omap3530.cfg
+++ b/tcl/target/omap3530.cfg
@@ -36,7 +36,8 @@ jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask
0x3f \
# GDB target: Cortex-A8, using DAP
set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap \
+ -variant omap3530
# SRAM: 64K at 0x4020.; use the first 16K
$_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
--
1.7.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Marek Vasut wrote: In this patch, I introduce the use of -variant parameter, so I can adjust the debug_base accordingly. This seems completely wrong to me. I think this logic should just stay in Tcl. So if anything, you would add a parameter for dap_base. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Shouldn't this be automatically detected? -- Øyvind Harboe 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
