Hi Lokesh, Judging from the stack trace, I'd suspect the problem you're seeing could be caused by gem5's generic timer model not supporting virtual timers. Some recent kernels insist in having this support and always touch those registers if a generic timer (aka architected timer) is present in the dtb. Depending on which register (we currently fake some of the registers and return the physical counter) the kernel touches, gem5 might raise an exception to indicate that the instruction was invalid.
I just posted a fix RB2762 [1] and RB2763 [2] that adds support for virtual timers. Try re-running with those patches applied if you still experience the problem. //Andreas [1] http://reviews.gem5.org/r/2762/ [2] http://reviews.gem5.org/r/2763/ On 03/18/15 21:31, Lokesh Jindal wrote:
Hello I am trying to boot a quadcore system (1 core per cluster| 4 clusters | per-core DVFS support | *dts file attached w**ith e-mail*) with arm_detailed CPU model. I am running with DVFS enabled linux-linaro gem5 specific kernel configured for ondemand governor. I am using the disk image ARMv7a-ICS-Android.SMP.Asimbench-v3.img that comes with asimbench. The simulation panics wih following message: info: trap check M:0 N:0 1:0 2:0 hdcr 0, hcptr 3fff, hstr 0 warn: Not doing anything for miscreg ACTLR warn: Not doing anything for write of miscreg ACTLR warn: instruction 'mcr bpiall' unimplemented 82292307048: system.cpu1.break_event: break event panic triggered 82292308476: system.cpu1.break_event: break event panic triggered 82292308476: system.cpu1.break_event: break event panic triggered 82292308476: system.cpu1.break_event: break event panic triggered 82292308476: system.cpu1.break_event: break event panic triggered The *system.terminal output (fi**le attached with the email)* is stuck at following point: Calibrating delay loop (skipped) preset value.. 3997.69 BogoMIPS (lpj=19988480) 52 ^Mpid_max: default: 32768 minimum: 301 53 ^MMount-cache hash table entries: 512 54 ^MCPU: Testing write buffer coherency: ok 55 ^MCPU0: update cpu_power 1024 56 ^MCPU0: thread -1, cpu 0, socket 0, mpidr 80000000 57 ^MSetting up static identity map for 0x8043d988 - 0x8043d9bc 58 ^M[<80015844>] (unwind_backtrace+0x0/0xf8) from [<80011d20>] (show_stack+0x10/0x14) 59 ^M[<80011d20>] (show_stack+0x10/0x14) from [<80439214>] (dump_stack+0x74/0xb4) 60 ^M[<80439214>] (dump_stack+0x74/0xb4) from [<80014840>] (handle_IPI+0x194/0x1c8) 61 ^M[<80014840>] (handle_IPI+0x194/0x1c8) from [<80008598>] (gic_handle_irq+0x54/0x5c) 62 ^M[<80008598>] (gic_handle_irq+0x54/0x5c) from [<80012800>] (__irq_svc+0x40/0x70) 63 ^MException stack(0x9f843ea0 to 0x9f843ee8) 64 ^M3ea0: 001f99f9 00000000 ea15aaf8 8033ae48 806972f4 000000fb 001f995c 80630eb0 65 ^M3ec0: 8061a414 00000000 9f875400 00000000 00000002 9f843ee8 800152b4 8033ae4c 66 ^M3ee0: a0000113 ffffffff 67 ^M[<80012800>] (__irq_svc+0x40/0x70) from [<8033ae4c>] (arch_counter_get_cntvct+0x4/0xc) 68 ^M[<8033ae4c>] (arch_counter_get_cntvct+0x4/0xc) from [<800152b4>] (arch_timer_read_counter_long+0x14/0x18) 69 ^M[<800152b4>] (arch_timer_read_counter_long+0x14/0x18) from [<8021fc54>] (__timer_delay+0x48/0x5c) 70 ^M[<8021fc54>] (__timer_delay+0x48/0x5c) from [<8001fa64>] (versatile_boot_secondary+0x94/0xd8) 71 ^M[<8001fa64>] (versatile_boot_secondary+0x94/0xd8) from [<8001406c>] (__cpu_up+0xa4/0x168) 72 ^M[<8001406c>] (__cpu_up+0xa4/0x168) from [<80022adc>] (cpu_up+0xe4/0x188) 73 ^M[<80022adc>] (cpu_up+0xe4/0x188) from [<805d7368>] (smp_init+0x68/0xac) 74 ^M[<805d7368>] (smp_init+0x68/0xac) from [<805c9bc4>] (kernel_init_freeable+0xd0/0x22c) 75 ^M[<805c9bc4>] (kernel_init_freeable+0xd0/0x22c) from [<80433d14>] (kernel_init+0x8/0x110) 76 ^M[<80433d14>] (kernel_init+0x8/0x110) from [<8000e378>] (ret_from_fork+0x14/0x3c) Interestingly, the *problem goes away when I change my CPU model in commandline from "arm_detailed" to "detailed"*. Does anyone have any ideas on this? I was under the impression that arm_detailed cpu was different from detailed CPU only in size of certain resources like buffer sizes, ALUs etc; but it seems there is more to it! Further, I am *able to boot with arm_detailed cpu with a single core*. Would really appreciate any help on understanding and resolving this issue! -- Regards Lokesh Jindal
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
