Re: [Xen-devel] ARM: EXYNOS 5410 - DOM0 not being scheduled

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-03-17 at 06:24 -0700, Suriyan Ramasami wrote:
> On Mon, Mar 17, 2014 at 3:09 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Sat, 2014-03-15 at 07:44 -0700, Suriyan Ramasami wrote:
> >>   I have been trying to get DOM0 to run on XEN on teh odroid-xu
> >> (Exynos 5410).
> >
> > Cool!
> It is exciting!
> 
> >
> >> chosen {
> >>     xen,xen-bootargs = "dom0_mem=512M console=dtuart
> >> dtuart=/serial@12C20000 earlyprintk=xen";
> >>     #size-cells = <0x1>;
> >>     #address-cells = <0x1>;
> >>     bootargs = "dom0_mem=512M console=dtuart dtuart=/serial@12C20000
> >> earlyprintk=xen";
> >>     module@0 {
> >>         bootargs = "console=hvc0,115200n8 root=/dev/mmcblk0p2 rw
> >> rootwait earlyprintk=xen console=ttySAC2,115200n8 mem=512M
> >> initcall_debug debug loglevel=10 psci=enable clk_ignore_unused";
> >
> > The console=hvc0 doesn't take the ",115200n8" bit -- although I don't
> > know if it will cause issues.
> >
> > Also you have a console=ttySAC2 in there -- I guess that is a second
> > serial port? Have you looked on that since your logs end at about the
> > point I'd expect dom0 to log something. Or you could just remove this
> > console= and leave hvc0 then dom0 should log to the Xen console which
> > will come out the Xen serial console.
> >
> > I don't think earlyprintk=xen will do anything for a 32-bit ARM kernel,
> > although I don't think it should be harmful.
> >
> I did a rerun with your suggestions. I trimmed the dom0_bootargs to:
> module@0 {
>         bootargs = "console=hvc0 root=/dev/mmcblk0p2 rw rootwait
> earlyprintk=xen lpj=4464640";
>         reg = <0x50000000 0x45b640>;
>         compatible = "xen,linux-zimage", "xen,multiboot-module";
>     };
> I still didn't see any output from dom0.

Weird, I'd expect something at least. One approach you can take here is
to hack in a call to xen_raw_printk somewhere in printk (I'm afraid I
have to rediscover exactly where from first principals each time).

> 
> > Do you have any DEBUG_LL related config options enabled in your dom0
> > kernel?
> I do not have them set. I will explore this route. Also, if you have
> any suggestions, please do let me know.
> >
> > Lastly if you press Ctrl-A three times then you get access to the Xen
> > debug key handlers (a bit like Linux's sysrq stuff), press 'h' for a
> > list of the available keys. 'd' or 'q' will dump the current register
> > state -- so you might be able to see where the dom0 vcpus think they are
> > and using System.map figure out if they are idling or they have crashed
> > etc (e.g. a PC == 0x0000000c or another small address corresponding to
> > an exception vector usually indicates an early crash).
> So I do get XEN to give me attention with Ctrl-a thrice. I hit 0 to
> get the dom0 registers.
> As mentioned in my reply to Julien, the PC register reflected the
> below (at least no crash was happening in dom0)

There was nothing below. Did you forget to insert something.

> With lpj not being passed in the dom0 kernel parameters it was looping
> in function do_calibrate().
> I then passed lpj in the dom0 kernel parameter, to help it move on. It
> then loops in do_xor_speed() in line - while ((now = jiffies) == j),
> implying jiffies is not being incremented - timer interrupt issues?

That sounds like the most plausible issue, yes.

Do you know which SPI the virt and physical timers are using on your
platform? If it is IRQ 31 then you might need to define a platform in
order to override dom0_evtchn_ppi and avoid a clash.

Is your dom0 kernel configuring/expecting phys or virt interrupts? 

I'm surprised you aren't getting any dom0 console though -- these hangs
should be well past the point where the console is working. You do have
the HVC driver and the XEN sub driver enabled in dom0, right?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel