From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgcb6-0006aF-An for qemu-devel@nongnu.org; Mon, 28 Sep 2015 13:52:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgcb2-00061x-3m for qemu-devel@nongnu.org; Mon, 28 Sep 2015 13:52:20 -0400 Received: from mail-la0-x230.google.com ([2a00:1450:4010:c03::230]:33944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgcb1-00061j-TH for qemu-devel@nongnu.org; Mon, 28 Sep 2015 13:52:16 -0400 Received: by labzv5 with SMTP id zv5so24256988lab.1 for ; Mon, 28 Sep 2015 10:52:15 -0700 (PDT) References: From: "mar.krzeminski" Message-ID: <56097E4D.6000104@gmail.com> Date: Mon, 28 Sep 2015 19:52:13 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Starting A9 from M3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" 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 > 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 >> >> >>