On 19/08/13 11:27, Greg Ungerer wrote:
> On 16/08/13 23:16, Greg Ungerer wrote:
>> On 16/08/13 22:48, Philip Craig wrote:
>>> On Fri, Aug 16, 2013 at 10:40 PM, Greg Ungerer <[email protected]> wrote:
>>>> Has anyone used openocd on the Marvell ARAMADA 370 SoC?
>>>>
>>>> I have a Globalscale Mirabox and am trying to get JTAG debugging working
>>>> on it. I am using an Amontec jtagkey, and have some basic functionality
>>>> working. But I can't access the bus in any way without getting errors
>>>> like this:
>>>>
>>>> > arm disassemble 0x0063C9A0 10
>>>> JTAG-DP STICKY ERROR
>>>> MEM_AP_CSW 0x28000d2, MEM_AP_TAR 0x63c9a0
>>>> JTAG-DP STICKY ERROR
>>>> MEM_AP_CSW 0x28000d2, MEM_AP_TAR 0x63c9a0
>>>> Block read error address 0x63c9a0
>>>> in procedure 'arm'
>>>>
>>>> I can halt the cpu, single step, set breakpoints and run to it.
>>>> I can dump the registers and get (what looks like) good values.
>>>> But just can't access anything on the bus.
>>>
>>> That sounds similar to a problem I was having with imx6. Try 'dap apcsw 1'.
>>
>> Thanks. Quick test seems to show it still produces the same error.
>> If I do "dap apcsw" I get back:
>>
>> apsel 0 selected, csw 0x40000000
>>
>> And I get the same result after running "dap apcsw 1". Not sure if
>> that is right.
>
> What I needed was:
>
> dap apsel 1
>
> After that I can sometimes disassemble at the stopped pc :-)
>
> When the unit is running linux (so MMU enabled) I can dissemble.
> But say when running uboot then it fails with:
>
> > halt
> target state: halted
> target halted in ARM state due to debug-request, current mode: Supervisor
> cpsr: 0x800001d3 pc: 0x00647ae0
> MMU: disabled, D-Cache: disabled, I-Cache: enabled
> > arm disassemble 0x00647ae0 5
> 647ae0 access in userspace and target in supervisor
The most immediate reason for this comes back to code in src/target/armv7a.c,
function armv7a_read_ttbcr(), which does this:
if (armv7a->armv7a_mmu.ttbr1_used == 1) {
LOG_INFO("SVC access above %x",
(0xffffffff & armv7a->armv7a_mmu.ttbr0_mask));
armv7a->armv7a_mmu.os_border = 0xffffffff &
armv7a->armv7a_mmu.ttbr0_mask;
} else {
/* fix me , default is hard coded LINUX border */
armv7a->armv7a_mmu.os_border = 0xc0000000;
}
That hard coded 0xc0000000 is causing the eventual address check in
cortex_a8_check_address(), src/target/cortex_a.c to fail.
Off hand I am not sure how best to change that, but in it currents form
it won't work for all cases.
Regards
Greg
> in procedure 'arm'
> > mdw 0x00647ae0 16
> 647ae0 access in userspace and target in supervisor
> in procedure 'mdw'
>
> Trying to access other memory regions results in errors like:
>
> > mdw 0xd0012000 16
> trying to enable mmu on target stopped with mmu disable
> in procedure 'mdw'
>
> Why is it trying to enable the MMU to do this?
>
> Regards
> Greg
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> OpenOCD-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
