On Mon, Sep 28, 2015 at 8:39 AM, Marcin Krzemiński
<mar.krzemin...@gmail.com> wrote:
> Hello,
>
> I am closer to finish, but still I found some problems this time booting
> from A9 cores from M3.
> Use case is that I M3 core loads firmware to SDRAM then A9 should begin to
> execute this firmware.
> I am starting M3 from elf, I see from debuger (gbd backend) that data are in
> SDRAM memory. Then I want to start A9.
> My reset function for A9 is:
>
> static void arm_a9(void *opaque)
> {
> CPUState *cpu = opaque;
> CPUClass *cc = CPU_GET_CLASS(cpu);
>
> cpu_reset(CPU(cpu));
>
> address_space_stl_notdirty(CPU(cpu)->as, PSS_SRAM_ADDR,
> 0, MEMTXATTRS_UNSPECIFIED, NULL);
>
> cc->set_pc(CPU(cpu),PSS_SRAM_ADDR);
> }
>
> registered in init of a9: qemu_register_reset(arm_reset,
> qemu_get_cpu(n->arm_a9_1_id));
> A9 is started in powered-off state: object_property_set_bool(cpuobj,
> true,"start-powered-off", &err);
>
> I have custom control device that after register write enable A9 in this
> way:
>
> static void release_cpu_from_reset(int cpu_id)
> {
> CPUState *cpu = NULL;
>
> if(cpu_id >= 0 && cpu_exists(cpu_id))
> {
> cpu = qemu_get_cpu(cpu_id);
> cpu_reset_interrupt(cpu, CPU_INTERRUPT_HALT);
> cpu_interrupt(cpu, CPU_INTERRUPT_EXITTB);
> cpu->halted = 0;
> }
> }
>
> I can see in debuger that A9 started in above way try to execute code(part
> of it seem to be successful), but then suddenly jumps to strange memory
> address (where zeroes are).
>
> My questions:
> 1. Is that way of dealing with A9 start is correct or am I still missing
> something?
> 2. Is is possible to somehow trace PC/instruction or something that can help
> with debugging?
>
-d in_asm,exec on command line will help. You may want to patch the
output prints to give the cpu ID # so you can tell difference between
A9 and M3.
Regards,
Peter
> I am suspecting that the firmware for A9 (it is u-boot-spl) has something to
> do with this, but I can't start debugging from the very firs instruction
> executed in A9.
>
> Thanks,
> Marcin
>
>
>
