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?

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

Reply via email to