This patchset adds support for the OMAP4430/Pandaboard and the ARM
Cortex-A9 CPU. For now I have clagged the A8 code into cortex_a9.c
to avoid breaking A8.
To deal with multiple cores exposed by one DAP, I've introduced a
'-coreid' target option, which does the obvious. At present, only
one of t
Hi Aaron,
thanks for submitting this! I am looking forward to having
a closer look when I get back next week.
--
Ø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 Cort
2011/1/24 Aaron Carroll
> This patchset adds support for the OMAP4430/Pandaboard and the ARM
> Cortex-A9 CPU. For now I have clagged the A8 code into cortex_a9.c
> to avoid breaking A8.
>
> To deal with multiple cores exposed by one DAP, I've introduced a
> '-coreid' target option, which does th
Hi Luca,
On 26 January 2011 00:13, luca ellero wrote:
> With your patch it seems to work. Anyway after issuing "halt" instruction, I
> always get the following message:
>
> target state: halted
> target halted in Thumb state due to debug-request, current mode: Supervisor
> cpsr: 0x6173 pc: 0x
On 27 January 2011 16:53, Aaron Carroll wrote:
> I think I've got an x-loader fix for this... I'm trying to test it now
> with Linux. Stay tuned.
I think we have a winner... try this patch:
diff --git a/board/omap4430panda/clock.c b/board/omap4430panda/clock.c
index 792e5d6..7f391f0 100644
---
Hi Aaron,
On 27/01/2011 6.53, Aaron Carroll wrote:
Hi Luca,
On 26 January 2011 00:13, luca ellero wrote:
With your patch it seems to work. Anyway after issuing "halt" instruction, I
always get the following message:
target state: halted
target halted in Thumb state due to debug-request, curr
Hi Luca,
On 28 January 2011 01:04, luca ellero wrote:
> I think it could be useful reporting here an opeonocd session with Mistral
> EVM3530 (OMAP 3530), _without_ an SD, so we are in an similar environment
> (3530 has boot ROM mapped at 0x14000, see OMAP 3530 TRM 25.4.2.1).
>
> Open On-Chip Debu
Hi Aaron,
On 28/01/2011 5.45, Aaron Carroll wrote:
The reason that you can't read the ROM through the debugger is because
it reads memory through the AHB-AP, which sits on the L3 interconnect.
However, the ROM is actually on the A9's internal L2 interconnect.
On the L3, 0x40028000 doesn't map t
Hi Luca,
On 28/01/11 22:18, luca ellero wrote:
I think it would be easy to add a flag or similar to the memory dump
commands in OpenOCD to have the A9 issue memory accesses on behalf of
the debugger, so we can access resources on the L2 interconnect... it
is already like this on some CPUs. Not s
On 01/29/2011 08:43 AM, Aaron Carroll wrote:
I wonder what the best way to is to implement this. One option could
be a table that maps address ranges to access methods. This would
have to be configured both cpu-cpu (e.g. Cortex-A9 per-core timers)
and per-SoC (e.g. OMAP4430 ROM). This would
Merged.
Thanks!
Although this is not done, I think it will be helpful to have it merged
in the master branch so testing/cooperation can proceed more smoothly.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.z
Great, keep us posted. Actually, this will definitely be generally
useful, because there are many other resources that can't be accessed
from the L3 interconnect: the MPCore private regions (per-core timers
and WDT), snoop-control unit, global interrupt controller, local PRCM,
and of course ROM. A
12 matches
Mail list logo
