Re: [Embedded-pv-devel] Xen RAM entry

[RAMYA RAVICHANDRAN <ramya.r@xxxxxxxxxxxxxxxxxxx>]

Hello Andrii and Embedded PV developers,

Thanks for your prompt hints.

There is a modification in the present device tree used for latest J6 Processor SDK.

The modification is the peripherals' interrupts are connected via CROSSBAR_MPU to GIC.

It would be great if  suggest any procedure/ best practices to accomodate the above in Xen?

Thanks,

Ramya

On Fri, Dec 8, 2017 at 5:07 PM, Andrii Anisov <andrii.anisov@xxxxxxxxx> wrote:

Hello Ramya,

Unfortunately I can not help you with this exact issue, it should be debugged on the board.

But there is one more hint: XEN does not actually pass the device tree to Dom0, XEN creates cpu, memory, timer nodes for Dom0 accordingly to the dom0 configuration, than copies device nodes from the original device tree. So your dom0 might be missing some stuff described in cpus nodes.

Sincerely,

Andrii Anisov.

2017-12-07 11:27 GMT+02:00 RAMYA RAVICHANDRAN <ramya.r@xxxxxxxxxxxxxxxxxxx>:

Hello Andrii,

The suggestions worked for Data Abort crash.We are able to move forward.

The following is the crash happening due to timers.

Please let us know your valuabe inputs/experience.

Log:

 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1

[    0.000000] Preemptible hierarchical RCU implementation.

[    0.000000]  Build-time adjustment of leaf fanout to 32.

[    0.000000] NR_IRQS:16 nr_irqs:16 16

[    0.000000] of_irq_init: children remain, but no parents

[    0.000000] Function:omap2_gp_clockevent_init at 366 

[    0.000000] irq: no irq domain found for /ocp/crossbar@4a002a48 !

[    0.000000] Function:omap2_gp_clockevent_init at 370 

[    0.000000] Function:omap2_gp_clockevent_init at 372 

[    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000

[    0.000000] pgd = c0003000

[    0.000000] [00000000] *pgd=80000080004003, *pmd=00000000

[    0.000000] Internal error: Oops: a06 [#1] PREEMPT SMP ARM

[    0.000000] Modules linked in:

[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.84-g7e6588b179 #22

[    0.000000] Hardware name: Generic DRA74X (Flattened Device Tree)

[    0.000000] task: c0969c38 ti: c0964000 task.ti: c0964000

[    0.000000] PC is at omap2_gp_clockevent_init.constprop.3+0xa4/0x110

[    0.000000] LR is at setup_irq+0x48/0x94

[    0.000000] pc : [<c0919c98>]    lr : [<c0083770>]    psr: 600000d3

[    0.000000] sp : c0965f38  ip : c0965f18  fp : c0965f64

[    0.000000] r10: c0951e2c  r9 : c09b7000  r8 : 00000001

[    0.000000] r7 : c06abf94  r6 : c0845e40  r5 : c096bb80  r4 : c09b7d94

[    0.000000] r3 : 00000002  r2 : 00000000  r1 : ef006000  r0 : ffffffda

[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel

[    0.000000] Control: 30c5387d  Table: 80003000  DAC: fffffffd

[    0.000000] Process swapper/0 (pid: 0, stack limit = 0xc0964210)

[    0.000000] Stack: (0xc0965f38 to 0xc0966000)

[    0.000000] 5f20:                                                       00000001 00000000

[    0.000000] 5f40: c0965f64 00000000 c09b7000 ef649f00 00000000 ffffffff c0965f74 c0965f68

[    0.000000] 5f60: c0919d1c c0919c00 c0965f8c c0965f78 c0919db8 c0919d10 00000000 c09b7000

[    0.000000] 5f80: c0965f9c c0965f90 c0911fbc c0919db4 c0965ff4 c0965fa0 c090ec44 c0911fa0

[    0.000000] 5fa0: ffffffff ffffffff 00000000 c090e6e8 ffffffff 00000000 00000000 c0966400

[    0.000000] 5fc0: 00000000 c0951e2c 00000000 c09b7ad4 c0966488 c0951e28 c096af10 80007000

[    0.000000] 5fe0: 412fc0f2 00000000 00000000 c0965ff8 80008090 c090e994 00000000 00000000

[    0.000000] Backtrace: 

[    0.000000] [<c0919bf4>] (omap2_gp_clockevent_init.constprop.3) from [<c0919d1c>] (omap4_sync32k_timer_init+0x18/0x44)

[    0.000000]  r8:ffffffff r7:00000000 r6:ef649f00 r5:c09b7000 r4:00000000

[    0.000000] [<c0919d04>] (omap4_sync32k_timer_init) from [<c0919db8>] (omap5_realtime_timer_init+0x10/0x190)

[    0.000000] [<c0919da8>] (omap5_realtime_timer_init) from [<c0911fbc>] (time_init+0x28/0x38)

[    0.000000]  r5:c09b7000 r4:00000000

[    0.000000] [<c0911f94>] (time_init) from [<c090ec44>] (start_kernel+0x2bc/0x40c)

[    0.000000] [<c090e988>] (start_kernel) from [<80008090>] (0x80008090)

[    0.000000]  r10:00000000 r9:412fc0f2 r8:80007000 r7:c096af10 r6:c0951e28 r5:c0966488

[    0.000000]  r4:c09b7ad4

[    0.000000] Code: e5854184 ebdda6a5 e5942014 e3a03002 (e5823000) 

[    0.000000] ---[ end trace cb88537fdc8fa200 ]---

[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

Thanks,

Ramya

On Wed, Dec 6, 2017 at 10:19 PM, RAMYA RAVICHANDRAN <ramya.r@xxxxxxxxxxxxxxxxxxx> wrote:

Hello Andrii,

Thanks a ton for sharing your wonderful experience.

Have attached the dts file for your reference.

Turning Paging on error was resolved by modifying files for MLO.

We have ported kernel 4.4 to accomodate Xen.

We will do the suggested changes and let you know.

Thanking you a lot,

Ramya

On Wed, Dec 6, 2017 at 9:56 PM, Andrii Anisov <andrii.anisov@xxxxxxxxx> wrote:

Hello Ramya,

We have been working on getting Xen hypervisor up on TI DRA7xx J6 platform.

Ouch, I remembered, Jacinto6 for sure.

I see you managed you issues with XEN hang after "Turning paging on". What was that?

Also sharing the dts file with you for reference. 

No dts is attached though. 

We have modified the dom0_mem size from 512MB to 1.5GB, we are observing hang/crash at different functions. (ie powerdomain/ hwmod_init etc).

Recalling my experience with J6 I guess not all MMIO registers accessed by kernel during PRCM setup are described in dts. So XEN traps those accesses from Dom0 and bounce back with data abort. As a quick hack you should add those registers to your dts. I.e. to the dummy device node with reg property contained all required registers. Adding a dra7xx_specific_mapping() function to xen/arch/arm/platforms/omap5.c similar to omap5_specific_mapping() would be more clean way.

You should build your XEN with CONFIG_DEBUG enabled, so you will see print from do_trap_data_abort_guest() right before inject_dabt_exception() call. That print will show what register mappings are missed.

BTW, IIRC, J6 platform code in kernel had smc call in its depths. SMC is not allowed under xen, so you should cut it out as well, otherwise XEN will crash the domain.

Sincerely,

Andrii Anisov.

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/embedded-pv-devel