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