Re: [Xen-users] [Xen-Users] Issues Booting Dom0 on ARM Cortex A15

[Brandon Perez <a0225893@xxxxxx>]

On 06/18/2015 07:02 AM, Chen Baozi wrote:
> On Thu, Jun 18, 2015 at 10:41:14AM +0100, Julien Grall wrote:
> > Hi Chen,
> >
> > On 18/06/2015 02:33, Chen Baozi wrote:
> >
> > > On Wed, Jun 17, 2015 at 04:00:38PM -0400, Brandon Perez wrote:
> > > > On 06/17/2015 03:15 PM, Julien Grall wrote:
> > > > > Hello Brandon,
> > > > >
> > > > > On 17/06/2015 15:30, Brandon Perez wrote:
> > > > > > The console and keyhandler are receiving 'q' and '0', but nothing is
> > > > > > happening/being printed out. I suspect this is because they are
> > > > > > scheduled as tasklets, and are never getting a chance to run.
> > > > > >
> > > > > > Opening the debugger, it seems like I'm stuck doing timer softirqs and
> > > > > > handling timer interrupts continually. I'm going to double check the
> > > > > > timer settings in my device tree.
> > > > > Looking to your first log [1], it seems that CNTFRQ is not set correctly:
> > > > >
> > > > > Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 0 KHz
> > > > >
> > > > > The CNTFRQ register should be set by the firmware/bootloader. Does the
> > > > > Linux kernel is booting on baremetal with the same firmware/bootloader?
> > > > >
> > > > > If yes, do you use the same device tree?
> > > > >
> > > > > Regards,
> > > > Hi Julien,
> > > >
> > > >      Good catch! That seems to have been the issue. To answer your questions,
> > > > yes the kernel is booting with same firmware, bootloader, and device tree as
> > > > Xen.
> > > >
> > > >      The real issue actually stems from the uBoot code, which was not
> > > > properly setting the CNTFRQ register (which was indeed 0).
> > > >
> > > >      The CNTFRQ register being 0 lead to a whole slew of issues, the primary
> > > > of which being was that the timer interrupt ran extremely often, causing
> > > > progress in preemptable sections of code to be extremely slow.
> > > This reminds me that I have had a similar issue when doing OMAP5432 enablement.
> > > IIRC, OMAP5 uses a different platform register for system timer, and CNTFRQ
> > > is not actually used during platform initialisation in linux kernel. Maybe
> > > it would be a good idea to have a check whether your SoC has the same
> > > implementation?
> > How did you resolve it on OMAP5432?
> Well, it didn't make much trouble on the Xen side at that time. (I just have
> had some vague memory on that, so may not be accurate.) What should be taken
> care is it would effect dom0 linux initialization (e.g., should made a 1:1
> mapping for dom0 to let it initialise memory-mapped register correctly).
>
> Cheers,
>
> Baozi.
    The SoC I'm actually using is a DRA72 chip, which is similar, but 
not exactly the same as the OMAP5432. There are several external timers 
on this chip, but the timer controlled by the CNTFRQ is on the ARM 
Cortex core itself. The timer is used by Linux kernel during system 
initialization.
    On my SoC, there is special ROM code that performs the initial 
system bootup, and passes control to uBoot initially. This code runs in 
Secure mode, and so, to make changes to registers such as CNTFRQ, I have 
to make calls to their API via SMC calls. For whatever reason, they 
didn't setup CNTFRQ properly whenever they booted the system, so I had 
to make an SMC call to properly initialize the register.
   Once I changed the CNTFRQ register, my boot stopped having issues, 
and I was able to successfully jump to the kernel.
Brandon


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