[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-users] [Xen-Users] Issues Booting Dom0 on ARM Cortex A15
On 06/16/2015 10:50 AM, Brandon Perez wrote:
On 06/16/2015 09:50 AM, Brandon Perez wrote:
On 06/16/2015 03:50 AM, Ian Campbell wrote:
On Mon, 2015-06-15 at 16:59 -0400, Brandon Perez wrote:
Hello All,
I'm experiencing some issues with booting into a Dom0 Linux Kernel
on a embedded ARM Cortex A15 processor. Tracing through the code has
shown me that the code is stuck in the idle_loop() function
(xen/arch/arm/domain.c:41). The function responds to only soft IRQs,
and
there are no scheduled tasklets to run.
A little about my setup to start. I'm using uBoot to boot Xen,
which
is running a Linux 3.14 kernel. I'm currently on Xen's master branch,
where the Xen version is 4.6-unstable. The commit I'm operating at has
the id ecdae1cfaa7f6123decaa1b9d7205c3ff726b941.
After looking through the Xen code, I was unable to find a place
where it explicitly jumps into the Dom0 kernel, which was what I was
expecting to see. Is there somewhere in the source code where this is
the case that I just missed? Or, is the initial jump into the kernel
scheduled as a tasklet? If the latter is the case, then the kernel is
never scheduled as a tasklet in the source code.
Any tips on getting out the idle_loop() would be appreciated.
Thanks
in advance for your assistance.
Without wishing to sound flippant, the idle loop will be exited when
things are not idle, i.e. there is some work to do. If it is idling that
would usually imply that every vcpu is sleeping or blocked. There's no
tasklets involved in the initial jump to dom0, just a normal return to
guest context.
IME the most common cause when things appear broken and Xen is just idle
is incorrect console= on the dom0 kernel command line or not running a
getty in dom0, so you get no output. Both should be configured refer to
hvc0. Starting with console=hvc0 should get you some dom0 boot logs at
least.
If that doesn't help then please post full serial logs of your system
booting as far as it does, including the u-boot commands and any u-boot
scripts which are run, along with your kernel .config.
Also, when it is in this idling state you should be able to press the
Xen conswitch key (Ctrl-A by default) 3 times and then use the debug
keys (h for help, q and d give useful cpu and vcpu register state) to
see where dom0's vcpus are at, so please include some of those in the
logs.
A dom0 vcpu address of 0x000000xx often indicates your kernel has
crashed early which can be another thing which goes wrong during initial
bringup on a new system (although normally more noisily than I am
inferring from what you've said here, but without logs its hard to say
for sure this isn't happening).
It would also be useful to know exactly which SoC you are using.
Ian.
Hello Ian,
The SoC I'm using is the TI Dra72 (similar to the OMAP5432). As
such, I've been adapting the instructions at
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
I've attached the booting log, the uBoot commands I run to get the
system up, and my .config file for the kernel.
The log stops after "Freed x init memory.", and nothing is printed
out after that. Also, pressing CTRL-A three times does not bring up a
Xen prompt, and pressing those keys have no affect.
It's worth noting that I am able to successfully boot the Linux
kernel natively with uBoot.
This may or may not be relevant, but I have stepped through the Xen
booting using Trace32. What I noticed was that, in the start_xen()
function (xen/arch/arm/setup.c), the code immediately goes into the
idle_loop() (start_xen() -> switch_stack_and_jump() -> init_done() ->
idle_loop()). There is only 1 vCPU in my system currently.
Brandon
Ian,
I was parsing through the logs again, and I noticed that there's an
error with the console option I'm passing into Xen. I'm getting the
following lines: "Unable to initialize dtuart: -19" and "Bad console=
option 'dtuart'".
This would likely explain why CTRL-A is not working for me. However,
I'm confused as to why the dtuart option would not work.
Brandon
Ian,
I think I figured out what the problem was. For my uBoot args, I
selected "dtuart=serial2", when I should have selected "dtuart=serial0",
since this is the correct alias to the UART in my device tree.
Brandon
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users
|
