|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Problems running Xen 4.4 on OMAP5432 evm
Hi Ashish,
On Apr 26, 2014, at 0:56, Kapania, Ashish <akapania@xxxxxx> wrote:
> Hi Julien,
>
> Here's the console output I get:
>
> ## Booting kernel from Legacy Image at e0000000 ...
> Image Name: Xen
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 656156 Bytes = 640.8 KiB
> Load Address: 80200000
> Entry Point: 80200000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 825f0000
> Booting using the fdt blob at 0x825f0000
> Loading Kernel Image ... OK
> reserving fdt memory region: addr=825f0000 size=7000
> Using Device Tree in place at 825f0000, end 825f9fff
>
> Starting kernel ...
>
> - UART enabled -
> - CPU 00000000 booting -
> - Xen starting in Hyp mode -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 0000000080000000 - 00000000feffffff
> (XEN)
> (XEN) MODULE[1]: 00000000825f0000 - 00000000825f7000
> (XEN) MODULE[2]: 0000000080300000 - 0000000080800000
> (XEN) RESVD[0]: 00000000825f0000 - 00000000825f7000
> (XEN)
> (XEN) Command line: dom0_mem=128M sync_console console=dtuart dtuart=serial2
> noreboot
> (XEN) Placing Xen at 0x00000000fee00000-0x00000000ff000000
> (XEN) Xen heap: 00000000ee000000-00000000fe000000 (65536 pages)
> (XEN) Dom heap: 454656 pages
> (XEN) Domain heap initialised
> (XEN) Looking for UART console serial2
> Xen 4.5-unstable
> (XEN) Xen version 4.5-unstable (arm-linux-gnueabihf-gcc (crosstool-NG
> linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) 4.7.3 20130226
> (prerelease)) debug=y Thu Apr 24 10:04:50 PDT 2014
> (XEN) Latest ChangeSet: Mon Apr 14 15:14:47 2014 +0200 git:c82fbfe-dirty
> (XEN) Console output is synchronous.
> (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> (XEN) 32-bit Execution:
> (XEN) Processor Features: 00001131:00011011
> (XEN) Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN) Debug Features: 02010555
> (XEN) Auxiliary Features: 00000000
> (XEN) Memory Model Features: 10201105 20000000 01240000 02102211
> (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
> (XEN) Platform: TI OMAP5
> (XEN) Set AuxCoreBoot1 to 00000000fee0004c (0020004c)
> (XEN) Set AuxCoreBoot0 to 0x20
> (XEN) cpu node `/cpus/cpu@1`: #size-cells 1
> (XEN) DT missing boot CPU MPIDR[23:0]
> (XEN) Using only 1 CPU
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> (XEN) Using generic timer at 6144 KHz
> (XEN) GIC initialization:
> (XEN) gic_dist_addr=0000000048211000
> (XEN) gic_cpu_addr=0000000048212000
> (XEN) gic_hyp_addr=0000000048214000
> (XEN) gic_vcpu_addr=0000000048216000
> (XEN) gic_maintenance_irq=25
> (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Allocated console ring of 16 KiB.
> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> (XEN) Brought up 1 CPUs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Populate P2M 0x88000000->0x90000000 (1:1 mapping for dom0)
> (XEN) Loading kernel from boot module 2
> (XEN) Loading zImage from 0000000080300000 to
> 000000008fa00000-000000008feb1cc0
> (XEN) Loading dom0 DTB to 0x000000008f800000-0x000000008f806d8e
> (XEN) Scrubbing Free RAM: .................done.
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) **********************************************
> (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
> (XEN) ******* This option is intended to aid debugging of Xen by ensuring
> (XEN) ******* that all output is synchronously delivered on the serial line.
> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
> (XEN) ******* timekeeping. It is NOT recommended for production use!
> (XEN) **********************************************
> (XEN) 3... 2... 1...
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
> Xen)
> (XEN) Freed 264kB init memory.
>
> And the dom0 dump:
>
> (XEN) 'q' pressed -> dumping domain info (now=0x12:5CD00FFD)
> (XEN) General information for domain 0:
> (XEN) refcnt=3 dying=0 pause_count=0
> (XEN) nr_pages=32768 xenheap_pages=2 shared_pages=0 paged_pages=0
> dirty_cpus={} max_pages=4294967295
> (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=00000000
> (XEN) GICH_LRs (vcpu 0) mask=0
> (XEN) VCPU_LR[0]=0
> (XEN) VCPU_LR[1]=0
> (XEN) VCPU_LR[2]=0
> (XEN) VCPU_LR[3]=0
> (XEN) Rangesets belonging to domain 0:
> (XEN) Interrupts { }
> (XEN) I/O Memory { }
> (XEN) NODE affinity for domain 0: [0]
> (XEN) VCPU information and callbacks for domain 0:
> (XEN) VCPU0: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) pause_count=0 pause_flags=0
> (XEN) No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 0)
> (XEN) 'd' pressed -> dumping registers
> (XEN)
> (XEN) *** Dumping CPU0 guest state (d0v0): ***
> (XEN) ----[ Xen-4.5-unstable arm32 debug=y Tainted: C ]----
> (XEN) CPU: 0
> (XEN) PC: 0000000c
> (XEN) CPSR: 900001d7 MODE:32-bit Guest ABT
> (XEN) R0: 80004000 R1: 00000c12 R2: 80008000 R3: 80004000
> (XEN) R4: 80008000 R5: 00000000 R6: 0000000e R7: ffffffff
> (XEN) R8: 8f800000 R9: 80000000 R10:90000000 R11:10201105 R12:8fa000a8
> (XEN) USR: SP: 00000000 LR: 00000000
> (XEN) SVC: SP: 00000000 LR: 8fa0036c SPSR:000001d3
> (XEN) ABT: SP: 00000000 LR: 0000000c SPSR:900001d7
> (XEN) UND: SP: 00000000 LR: 00000000 SPSR:00000000
> (XEN) IRQ: SP: 00000000 LR: 00000000 SPSR:00000000
> (XEN) FIQ: SP: 00000000 LR: 00000000 SPSR:00000000
> (XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000
> (XEN)
> (XEN) SCTLR: 00c50078
> (XEN) TCR: 00000000
> (XEN) TTBR0: 0000000000000000
> (XEN) TTBR1: 0000000000000000
> (XEN) IFAR: 0000000c, IFSR: 00000002
> (XEN) DFAR: 80004000, DFSR: 00000002
> (XEN)
> (XEN) VTCR_EL2: 80003558
> (XEN) VTTBR_EL2: 00010000825fe000
> (XEN)
> (XEN) SCTLR_EL2: 30cd187f
> (XEN) HCR_EL2: 0000000000282435
> (XEN) TTBR0_EL2: 00000000feedf000
> (XEN)
> (XEN) ESR_EL2: 80000005
> (XEN) HPFAR_EL2: 0000000000000000
> (XEN) HDFAR: 80004000
> (XEN) HIFAR: 0000000c
> (XEN)
> (XEN) Guest stack trace from sp=0:
> (XEN) Failed to convert stack to physical address
> (XEN)
>
> The above output is with development branch xen from Apr14. I get the same
> output with xen v4.4 too.
I just tested the latest xen from git with a 3.11-rc3 dom0 kernel on my omap5432
uevm board. And seems all the problem I got is that dom0 was trying to access
some addresses hardcoded in hwmod that the hypervisor didn’t map according to
the info it got from DT.
I’ll have a test with latest upstream kernel these days and see what would
happen.
Cheers,
Baozi
>
> Best,
> Ashish
>
> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxxxxx]
> Sent: Friday, April 25, 2014 2:17 AM
> To: Kapania, Ashish; Ian Campbell
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Problems running Xen 4.4 on OMAP5432 evm
>
> Hi Anish,
>
> On 25/04/14 00:05, Kapania, Ashish wrote:
>> I apologize for causing any confusion. The xen.lds file I modified is
>> generated and hence not tracked by git. I had forgotten about the change and
>> running "git status"
>> was not telling me that I modified the file. Another point I wanted to
>> make was that I always do a "make distclean" before rebuilding xen but
>> the xen.lds file does not get regenerated. I had to manually delete it to
>> force regeneration.
>> Maybe that’s a bug ?
>>
>> I tried the Ctrl-A * 3 + press 'd' sequence and found that dom0 is in ABT
>> mode.
>> I tried debugging a little with JTAG (My JTAG setup does not work well
>> in HYP Mode so I cannot debug xen with it) and found that the ABT
>> happens in Linux/arch/arm/boot/compressed/head.S's __setup_mmu code.
>> The exact instruction that causes the abort is a store instruction
>> that is attempting to write a page table entry to 0x80004000.
>>
>> MMU stage 1 translation is disabled at this point so it looks like the
>> Stage 2 translation is not mapping 0x80004000 address. Is there some
>> step that I am missing that is suppose to tell xen to map the memory
>> used by linux to store page tables ?
>
> Can you post the console output of Xen and DOM0 (if you have some)? I'd like
> to seems how Xen populates the RAM for DOM0.
>
> Regards,
>
> --
> Julien Grall
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |