Hi,
I have been trying to get Dom0 running on OMAP5 for a while now.
Right now i can''t get even a single print from Dom0.
Based on a recent thread on the list i have tried adding
xen_raw_console_write() in vprintk_emit() but even that doesn''t help.
Strangely Xen keyhandlers other than ''d'' are not working so i
can''t even
get Dom0 state dump.
I have tested the zImage boot on the board via bootz command of U-Boot
and that works fine.
Is there any constraint on where the xen-uImage and zImage should be
loaded? Any suggestions on how i could debug this?
So far i get just the following prints from Xen...
U-Boot# bootm $xen_addr_r - $dtb_addr_r
## Booting kernel from Legacy Image at 90000000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 656180 Bytes = 640.8 KiB
Load Address: 80200000
Entry Point: 80200000
Verifying Checksum ... OK
## Flattened Device Tree blob at a2000000
Booting using the fdt blob at 0xa2000000
Loading Kernel Image ... OK
reserving fdt memory region: addr=a2000000 size=b000
Using Device Tree in place at a2000000, end a200dfff
Trying to enter hypervisor mode
Starting kernel ...
- UART enabled -
- CPU 00000000 booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
Checking for initrd in /chosen
banks present 1
bank 0 start 0000000080000000size 000000007f000000
RAM: 0000000080000000 - 00000000feffffff
MODULE[1]: 00000000a2000000 - 00000000a200b000
MODULE[2]: 00000000a0000000 - 00000000a0a00000
RESVD[0]: 00000000a2000000 - 00000000a200b000
Placing Xen at 0x00000000fee00000-0x00000000ff000000
Xen heap: 00000000ee000000-00000000fe000000 (65536 pages)
Dom heap: 454656 pages
Looking for UART console serial2
__ __ _ _ _ _ _ _ _
\ \/ /___ _ __ | || | | || | _ _ _ __ ___| |_ __ _| |__ | | ___
\ // _ \ ''_ \ | || |_| || |_ __| | | | ''_ \/ __| __/ _` |
''_ \| |/ _ \
/ \ __/ | | | |__ _|__ _|__| |_| | | | \__ \ || (_| | |_) | | __/
/_/\_\___|_| |_| |_|(_) |_| \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 4.4-unstable (vaibhav@) (arm-linux-gnueabi-gcc
(Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3) debug=y Sun Oct 20 09:36:13 EDT
2013
(XEN) Latest ChangeSet: Sat Oct 19 19:12:52 2013 -0400 git:871c1d1-dirty
(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) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer
at 0 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 0xb0000000->0xc0000000 (1:1
mapping for dom0) (XEN) Loading
kernel from boot module 2
(XEN) zImage present @
00000000a0000000size is 0000000000a00000
(XEN) zImage start 0
(XEN) zImage end 4165032
(XEN) Kernel
starts @00000000a0000000
(XEN) We are PIC
(XEN) load_end 00000000c0000000
(XEN) load_end
00000000b8000000
(XEN) load_end 00000000b8000000
(XEN) load_addr 00000000b7c07258
(XEN)
load_addr 00000000b7c00000
(XEN) Loading zImage from
00000000a0000000 to 00000000b7c00000-00000000b7ff8da8 (XEN)
Loading dom0 DTB to 0x00000000b8000000-0x00000000b800a707
(XEN) Setting pc for jump to b7c00000
(XEN) DT address passed 00000000b8000000
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch
input to Xen) (XEN) Freed 264kB init memory.
(XEN) *** Serial input -> Xen (type
''CTRL-a'' three
times to switch input to DOM0)
(XEN) ''d'' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 host state: ***
(XEN) ----[ Xen-4.4-unstable arm32 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) PC: 00228a08 _spin_unlock_irq+0x68/0x78
(XEN) CPSR: 2000005a MODE:Hypervisor
(XEN) R0: 002e6380 R1: 00000000 R2: 00000000 R3: 00000000
(XEN) R4: 00000000 R5: 00000000 R6: 002e6380 R7: 4ffe27f8
(XEN) R8: 400054c0 R9: 002e4254 R10:00264b80 R11:4000fee4 R12:002e6400
(XEN) HYP: SP: 4000fed4 LR: 0022bd28
(XEN)
(XEN) VTCR_EL2: 80002558
(XEN) VTTBR_EL2: 00010000a200e000
(XEN)
(XEN) SCTLR_EL2: 30cd187f
(XEN) HCR_EL2: 0000000000282835
(XEN) TTBR0_EL2: 00000000feedf000
(XEN)
(XEN) ESR_EL2: 00000000
(XEN) HPFAR_EL2: 0000000000000000
(XEN) HDFAR: 00000000
(XEN) HIFAR: 00000000
(XEN)
(XEN) Xen stack trace from sp=4000fed4:
(XEN) 0024b4b8 00000001 00000000 4000ff04 0022bd28 00000000 002b1ff0 00000000
(XEN) 002ae000 002e7614 00264b80 4000ff2c 00227e7c 00000013 002e7614 002e7614
(XEN) 002e7614 002e7614 002e6310 00000000 00010000 4000ff34 00227f0c 4000ff54
(XEN) 00243cf8 4000ff58 00264b8c 00264b8c 00000002 0029fee8 fe000000 4000ff4c
(XEN) 0024b2f8 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000
(XEN) Xen call trace:
(XEN) [<00228a08>] _spin_unlock_irq+0x68/0x78 (PC)
(XEN) [<0022bd28>] timer_softirq_action+0x20c/0x230 (LR)
(XEN) [<0022bd28>] timer_softirq_action+0x20c/0x230
(XEN) [<00227e7c>] __do_softirq+0xe8/0xec
(XEN) [<00227f0c>] do_softirq+0x14/0x18
(XEN) [<00243cf8>] idle_loop+0x168/0x198
(XEN) [<0024b2f8>] init_done+0x10/0x14
(XEN)
Regards,
Vaibhav
On Sun, 2013-10-20 at 10:01 -0400, Vaibhav Bedia wrote:> MODULE[1]: 00000000a2000000 - 00000000a200b000 > MODULE[2]: 00000000a0000000 - 00000000a0a00000You don''t seem to have given dom0 any kind of command line. Try "console=hvc0". You have the Xen options, including the hvc console, enabled in your kernel I hope. Ian.
Hi Ian, On Sun, Oct 20, 2013 at 11:42 AM, Ian Campbell <ian.campbell@citrix.com> wrote:> On Sun, 2013-10-20 at 10:01 -0400, Vaibhav Bedia wrote: >> MODULE[1]: 00000000a2000000 - 00000000a200b000 >> MODULE[2]: 00000000a0000000 - 00000000a0a00000 > > You don''t seem to have given dom0 any kind of command line. Try > "console=hvc0". You have the Xen options, including the hvc console, > enabled in your kernel I hope. >I am trying to set xen,dom0-bootargs using the fdt command of U-Boot. I did have to fight the double quotes that fdt set was putting in but i managed to fix that. I did enable the various Xen options including the hvc console in the kernel. Just before invoking xen, here''s what fdt list shows: U-Boot# fdt list /chosen chosen { xen,dom0-bootargs = "console=hvc0,115200n8 vram=16M root=/dev/ram initrd=0x83000000,16M ramdisk_size=65536 rw earlyprintk=xen"; xen,xen-bootargs = "dom0_mem=256M console=dtuart dtuart=serial2 earlyprintk=xen"; modules { }; }; U-Boot# Does this look right?
On Sun, Oct 20, 2013 at 12:02 PM, Vaibhav Bedia <vaibhav.bedia@gmail.com> wrote:> Hi Ian, > > On Sun, Oct 20, 2013 at 11:42 AM, Ian Campbell <ian.campbell@citrix.com> wrote: >> On Sun, 2013-10-20 at 10:01 -0400, Vaibhav Bedia wrote: >>> MODULE[1]: 00000000a2000000 - 00000000a200b000 >>> MODULE[2]: 00000000a0000000 - 00000000a0a00000 >> >> You don''t seem to have given dom0 any kind of command line. Try >> "console=hvc0". You have the Xen options, including the hvc console, >> enabled in your kernel I hope. >> > > I am trying to set xen,dom0-bootargs using the fdt command of U-Boot. > I did have to fight > the double quotes that fdt set was putting in but i managed to fix that. > > I did enable the various Xen options including the hvc console in the kernel. > > Just before invoking xen, here''s what fdt list shows: > U-Boot# fdt list /chosen > chosen { > xen,dom0-bootargs = "console=hvc0,115200n8 vram=16M > root=/dev/ram initrd=0x83000000,16M ramdisk_size=65536 rw > earlyprintk=xen"; > xen,xen-bootargs = "dom0_mem=256M console=dtuart > dtuart=serial2 earlyprintk=xen"; > modules { > }; > }; > U-Boot# > > Does this look right?Argh... i should have not ignored the timer running @ 0Hz message for so long. With that fixed in DTB i can see Dom0 crash now. And somehow that change made the other Xen keyhandlers work again!
On Sun, Oct 20, 2013 at 12:35 PM, Vaibhav Bedia <vaibhav.bedia@gmail.com> wrote:> On Sun, Oct 20, 2013 at 12:02 PM, Vaibhav Bedia <vaibhav.bedia@gmail.com> wrote: >> Hi Ian, >> >> On Sun, Oct 20, 2013 at 11:42 AM, Ian Campbell <ian.campbell@citrix.com> wrote: >>> On Sun, 2013-10-20 at 10:01 -0400, Vaibhav Bedia wrote: >>>> MODULE[1]: 00000000a2000000 - 00000000a200b000 >>>> MODULE[2]: 00000000a0000000 - 00000000a0a00000 >>> >>> You don''t seem to have given dom0 any kind of command line. Try >>> "console=hvc0". You have the Xen options, including the hvc console, >>> enabled in your kernel I hope. >>> >> >> I am trying to set xen,dom0-bootargs using the fdt command of U-Boot. >> I did have to fight >> the double quotes that fdt set was putting in but i managed to fix that. >> >> I did enable the various Xen options including the hvc console in the kernel. >> >> Just before invoking xen, here''s what fdt list shows: >> U-Boot# fdt list /chosen >> chosen { >> xen,dom0-bootargs = "console=hvc0,115200n8 vram=16M >> root=/dev/ram initrd=0x83000000,16M ramdisk_size=65536 rw >> earlyprintk=xen"; >> xen,xen-bootargs = "dom0_mem=256M console=dtuart >> dtuart=serial2 earlyprintk=xen"; >> modules { >> }; >> }; >> U-Boot# >> >> Does this look right? > > Argh... i should have not ignored the timer running @ 0Hz message for so long. > With that fixed in DTB i can see Dom0 crash now. And somehow that change made > the other Xen keyhandlers work again!Hello, I have managed to get Dom0 reach the point where it tries to mount a filesystem (ramdisk in my case) and then crashes. Looking at the logs i noticed that the initrd is located outside the phys area that kernel is aware of and hence getting ignored. [...] [0.000000] INITRD: 0x83000000+0x01000000 is not a memory region - disabling initrd In the bootargs i have specified the initrd to be located to 0x83000000 and that obviously isn''t working. What is the right way to specify the initrd location to Dom0? Does it depend on where Xen relocates the initrd? The following is what Xen prints during boot. ... (XEN) Loading zImage from 00000000a0000000 to 00000000b7a00000-00000000b7e055e0 (XEN) Loading dom0 initrd from 00000000a4000000 to 0x00000000b8200000-0x00000000b8c00000 (XEN) Loading dom0 DTB to 0x00000000b8000000-0x00000000b800c46b ... Regards, Vaibhav
On Wed, 2013-10-23 at 20:13 -0400, Vaibhav Bedia wrote:> Looking at the logs i noticed that the initrd is located outside the > phys area that kernel > is aware of and hence getting ignored. > > [...] > [0.000000] INITRD: 0x83000000+0x01000000 is not a memory region - > disabling initrd > > In the bootargs i have specified the initrdDo you mean the bootargs given to Xen or the ones given to dom0? How exactly did you do this.> to be located to > 0x83000000 and that obviously isn''t working. What is the right way to specify the initrd location to > Dom0? Does it depend on where Xen relocates the initrd?Xen itself chooses where the initrd lives in the guest physical address space, based on various constraints documented in linux/Documentation/arm/booting.txt. This stuff is a bit new so I suppose there could still be issues. Certainly if it is placing the initrd outside of the guest''s RAM area then that is a issue! For this to work you (or your bootloader) need to be specifying the location of the initrd in the host memory space at boot time, Xen will then copy it into guest space and setup the DT given to dom0 to reference it. Ian.> > The following is what Xen prints during boot. > ... > (XEN) Loading zImage from 00000000a0000000 to 00000000b7a00000-00000000b7e055e0 > (XEN) Loading dom0 initrd from 00000000a4000000 to > 0x00000000b8200000-0x00000000b8c00000 > (XEN) Loading dom0 DTB to 0x00000000b8000000-0x00000000b800c46b > ... > > Regards, > Vaibhav
Hi Ian, On Thu, Oct 24, 2013 at 4:18 AM, Ian Campbell <ian.campbell@citrix.com> wrote:> On Wed, 2013-10-23 at 20:13 -0400, Vaibhav Bedia wrote: > >> Looking at the logs i noticed that the initrd is located outside the >> phys area that kernel >> is aware of and hence getting ignored. >> >> [...] >> [0.000000] INITRD: 0x83000000+0x01000000 is not a memory region - >> disabling initrd >> >> In the bootargs i have specified the initrd > > Do you mean the bootargs given to Xen or the ones given to dom0? How > exactly did you do this. >I specified that in the bootargs being passed to Dom0. U-Boot# fdt set /chosen xen,dom0-bootargs \"console=hvc0,115200n8 vram=16M root=/dev/ram initrd=0x83000000,16M ramdisk_size=65536 rw earlyprintk=xen lpj=61440 nohlt\">> to be located to >> 0x83000000 and that obviously isn''t working. What is the right way to specify the initrd location to >> Dom0? Does it depend on where Xen relocates the initrd? > > Xen itself chooses where the initrd lives in the guest physical address > space, based on various constraints documented in > linux/Documentation/arm/booting.txt. This stuff is a bit new so I > suppose there could still be issues. Certainly if it is placing the > initrd outside of the guest''s RAM area then that is a issue! > > For this to work you (or your bootloader) need to be specifying the > location of the initrd in the host memory space at boot time, Xen will > then copy it into guest space and setup the DT given to dom0 to > reference it. >Ok something odd happened just now. I formatted a micro-SD card to try out a filesystem that. I guess something went wrong in the formatting and that failed but the initrd got mounted! I think this happened because i replaced the initrd related stuff from dom0-bootargs with the ones for SD boot. To confirm this, i completely removed the root=<xyz> stuff from dom0-bootargs and now i can get the ramdisk to work fine. So, is not specifying anything in the dom0-bootargs the right way to make this thing work? Regards, Vaibhav
On Thu, 2013-10-24 at 06:17 -0400, Vaibhav Bedia wrote:> Hi Ian, > > On Thu, Oct 24, 2013 at 4:18 AM, Ian Campbell <ian.campbell@citrix.com> wrote: > > On Wed, 2013-10-23 at 20:13 -0400, Vaibhav Bedia wrote: > > > >> Looking at the logs i noticed that the initrd is located outside the > >> phys area that kernel > >> is aware of and hence getting ignored. > >> > >> [...] > >> [0.000000] INITRD: 0x83000000+0x01000000 is not a memory region - > >> disabling initrd > >> > >> In the bootargs i have specified the initrd > > > > Do you mean the bootargs given to Xen or the ones given to dom0? How > > exactly did you do this. > > > > I specified that in the bootargs being passed to Dom0. > U-Boot# fdt set /chosen xen,dom0-bootargs \"console=hvc0,115200n8 > vram=16M root=/dev/ram initrd=0x83000000,16M ramdisk_size=65536 rw > earlyprintk=xen lpj=61440 nohlt\"OK, this won''t work.You''ve told dom0 that there is an initrd at 0x83000000 but nothing here will actually be causing that to be the case. You need to pass an initrd boot module to Xen, using the fdt based protocol described in http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD Xen will then take care of passing things to dom0. Ian.
On Thu, Oct 24, 2013 at 6:31 AM, Ian Campbell <ian.campbell@citrix.com> wrote:> On Thu, 2013-10-24 at 06:17 -0400, Vaibhav Bedia wrote: >> Hi Ian, >> >> On Thu, Oct 24, 2013 at 4:18 AM, Ian Campbell <ian.campbell@citrix.com> wrote: >> > On Wed, 2013-10-23 at 20:13 -0400, Vaibhav Bedia wrote: >> > >> >> Looking at the logs i noticed that the initrd is located outside the >> >> phys area that kernel >> >> is aware of and hence getting ignored. >> >> >> >> [...] >> >> [0.000000] INITRD: 0x83000000+0x01000000 is not a memory region - >> >> disabling initrd >> >> >> >> In the bootargs i have specified the initrd >> > >> > Do you mean the bootargs given to Xen or the ones given to dom0? How >> > exactly did you do this. >> > >> >> I specified that in the bootargs being passed to Dom0. >> U-Boot# fdt set /chosen xen,dom0-bootargs \"console=hvc0,115200n8 >> vram=16M root=/dev/ram initrd=0x83000000,16M ramdisk_size=65536 rw >> earlyprintk=xen lpj=61440 nohlt\" > > OK, this won''t work.You''ve told dom0 that there is an initrd at > 0x83000000 but nothing here will actually be causing that to be the > case. > > You need to pass an initrd boot module to Xen, using the fdt based > protocol described in > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/booting.txt;h=9802e5e20fd8c7da94eaa7b639b7530b951760eb;hb=HEAD > Xen will then take care of passing things to dom0.It works if i skip the initrd stuff in dom0-bootargs. I also got the filesystem on SD working now :) root@arm:~# uname -a Linux arm 3.12.0-rc5-00671-geb765a3-dirty #25 SMP Wed Oct 23 22:58:51 EDT 2013 armv7l GNU/Linux root@arm:~# cat /proc/interrupts CPU0 31: 295 GIC 31 events 39: 0 GIC 39 palmas 41: 0 GIC 41 l3-dbg-irq 42: 0 GIC 42 l3-app-irq 44: 3477 GIC 44 DMA 69: 5033 GIC 69 gp_timer 88: 1406 GIC 88 48070000.i2c 92: 0 GIC 92 4807c000.i2c 112: 13 GIC 112 4ae14000.wdt 115: 4659 GIC 115 mmc1 118: 421 GIC 118 mmc0 158: 2 GIC 158 talert 192: 0 xen-dyn-event xenbus 345: 0 GPIO 24 mmc1 449: 294 xen-percpu-virq hvc_console 451: 0 palmas 21 palmas_usb_id 453: 0 palmas 23 palmas_usb_vbus IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts Err: 0 Now i need to figure out how to get a working domU. Thanks, Vaibhav