[Qemu-devel] Starting A9 from M3

[Qemu-devel] Starting A9 from M3

[Marcin Krzemiński]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2703 bytes --]

Re: [Qemu-devel] Starting A9 from M3

[Peter Crosthwaite]

On Mon, Sep 28, 2015 at 8:39 AM, Marcin Krzemiński
<mar.krzeminski@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
>
>
>

Re: [Qemu-devel] Starting A9 from M3

[mar.krzeminski]

The problem was related to my SDRAM hw specific implementation.
There is only 64KiB starting from address 0xFFF00000, but the address 
space has 1MiB.
Space above 64KiB is constantly remapped to real location.
In my model I used 1MiB memory chunk instead of aliasing, so the A9s 
reset vector has 0s.
Thanks for help and hint how to debug.

Regards,
Marcin

W dniu 28.09.2015 o 19:00, Peter Crosthwaite pisze:
> On Mon, Sep 28, 2015 at 8:39 AM, Marcin Krzemiński
> <mar.krzeminski@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
>>
>>
>>

Re: [Qemu-devel] Starting A9 from M3

[Peter Maydell]

On 28 September 2015 at 18:00, Peter Crosthwaite
<crosthwaitepeter@gmail.com> wrote:
> -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.

You had a patch for that, didn't you? I can't remember why
we didn't put it in...

-- PMM