* ARM: EXYNOS 5410 - DOM0 not being scheduled
@ 2014-03-15 14:44 Suriyan Ramasami
2014-03-16 20:31 ` Julien Grall
2014-03-17 10:09 ` Ian Campbell
0 siblings, 2 replies; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-15 14:44 UTC (permalink / raw)
To: xen-devel
Hello Friends,
I have been trying to get DOM0 to run on XEN on teh odroid-xu
(Exynos 5410). xen boots up in hyp mode. I can get all 4 CPU cores to
come up. Confirmed that the Arch generic timer is ticking (note the
output of the timer and the reread of the same timer for different
values). Any pointers on where I should concentrate on to debug would
be helpful. I do see that softirq_haldler[1] is never called which is
the call to schedule().
I am posting the full boot logs. Any help is appreciated.
Thanks
- Suriyan
U-Boot 2012.07-g612e625-dirty (Mar 14 2014 - 17:57:52) for Exynos5410
CPU: Exynos5410 Rev2.3 [Samsung SOC on SMP Platform Base on ARM CortexA15]
APLL = 900MHz, KPLL = 600MHz
MPLL = 532MHz, BPLL = 800MHz
DRAM: 2 GiB
WARNING: Caches not enabled
TrustZone Enabled BSP
BL1 version:
PMIC VER : 0, CHIP REV : 6
VDD MIF : 1.00000V
VDD ARM : 1.00000V
VDD INT : 1.00000V
VDD G3D : 1.00000V
VDD KFC : 1.00000V
Checking Boot Mode ... SDMMC
MMC: S5P_MSHC2: 0, S5P_MSHC0: 1
MMC Device 0: 7.4 GiB
MMC Device 1: [ERROR] response error : 00000006 cmd 8
[ERROR] response error : 00000006 cmd 55
[ERROR] response error : 00000006 cmd 2
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Press 'Enter' or 'Space' to stop autoboot: 0
there are pending interrupts 0x00000001
reading boot.ini
2555 bytes read
Loading boot.ini from FAT
Find boot.ini file from FAT/Ext4 Area!!
boot.ini command = echo fatload mmc 0:1 $kernel_addr_r $kernel_path
fatload mmc 0:1 0x50000000 linux3.13-zimage
boot.ini command = fatload mmc 0:1 $kernel_addr_r $kernel_path
reading linux3.13-zimage
4688744 bytes read
boot.ini command = echo setenv linux_size 0x$filesize
setenv linux_size 0x478B68
boot.ini command = setenv linux_size 0x$filesize
boot.ini command = echo fatload mmc 0:1 $xen_addr_r $xen_path
fatload mmc 0:1 0x41000000 xen4.4-uImage
boot.ini command = fatload mmc 0:1 $xen_addr_r $xen_path
reading xen4.4-uImage
656208 bytes read
boot.ini command = echo fatload mmc 0:1 $dtb_addr_r $dtb_path
fatload mmc 0:1 0x60000000 /exynos5410-odroidxu.dtb
boot.ini command = fatload mmc 0:1 $dtb_addr_r $dtb_path
reading /exynos5410-odroidxu.dtb
26961 bytes read
boot.ini command = fdt addr $dtb_addr_r
boot.ini command = fdt resize
boot.ini command = fdt set /chosen \#address-cells <1>
boot.ini command = fdt set /chosen \#size-cells <1>
boot.ini command = fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
boot.ini command = fdt set /chosen bootargs \"$xen_bootargs\"
boot.ini command = fdt mknod /chosen module@0
boot.ini command = fdt set /chosen/module@0 compatible
"xen,linux-zimage" "xen,multiboot-module"
boot.ini command = fdt set /chosen/module@0 reg <${kernel_addr_r} ${linux_size}>
boot.ini command = fdt set /chosen/module@0 bootargs \"$dom0_bootargs\"
boot.ini command = fdt list /chosen
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 {
};
};
boot.ini command = fdt print /chosen
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";
reg = <0x50000000 0x478b68>;
compatible = "xen,linux-zimage", "xen,multiboot-module";
};
};
boot.ini command = bootm $xen_addr_r - $dtb_addr_r
## Booting kernel from Legacy Image at 41000000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 656144 Bytes = 640.8 KiB
Load Address: 80200000
Entry Point: 80200000
Verifying Checksum ... OK
## Flattened Device Tree blob at 60000000
Booting using the fdt blob at 0x60000000
Loading Kernel Image ... OK
OK
reserving fdt memory region: addr=60000000 size=7000
Using Device Tree in place at 60000000, end 60009fff
CPU0: Power: 3 status: 3
CPU0: Power: 3 status: 3 Its powered on!
CPU1: Power: 0 status: 0
CPU1: Power: 3 status: 0 Its powered on!
CPU2: Power: 0 status: 0
CPU2: Power: 3 status: 0 Its powered on!
CPU3: Power: 0 status: 0
CPU3: Power: 3 status: 0 Its powered on!
The MCT timer is now on - Arch timer will start counting
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
RAM: 0000000040000000 - 000000004fffffff
RAM: 0000000050000000 - 000000005fffffff
RAM: 0000000060000000 - 000000006fffffff
RAM: 0000000070000000 - 000000007fffffff
RAM: 0000000080000000 - 000000008fffffff
RAM: 0000000090000000 - 000000009fffffff
RAM: 00000000a0000000 - 00000000afffffff
RAM: 00000000b0000000 - 00000000bfdfffff
MODULE[1]: 0000000060000000 - 000000006000a000
MODULE[2]: 0000000050000000 - 0000000050478b68 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
RESVD[0]: 0000000060000000 - 0000000060007000
Command line: dom0_mem=512M console=dtuart dtuart=/serial@12C20000
earlyprintk=xen
Placing Xen at 0x00000000bfc00000-0x00000000bfe00000
Xen heap: 00000000ae000000-00000000be000000 (65536 pages)
Dom heap: 458240 pages
Xen 4.4.0r UART console /serial@12C20000
(XEN) Xen version 4.4.0 (suriyan@) (arm-linux-gcc (Buildroot 2014.02)
4.7.3) debug=y Sat Mar 15 07:40:02 PDT 2014
(XEN) Latest ChangeSet:
(XEN) Processor: 412fc0f3: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x3
(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: SAMSUNG EXYNOS5
(XEN) Set SYSRAM to 00000000bfc0004c (0020004c)
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer at 24000 KHz
(XEN) boot_count: 47899952 reread: 47982870
(XEN) GIC initialization:
(XEN) gic_dist_addr=0000000010481000
(XEN) gic_cpu_addr=0000000010482000
(XEN) gic_hyp_addr=0000000010484000
(XEN) gic_vcpu_addr=0000000010486000
(XEN) gic_maintenance_irq=25
(XEN) GIC: 256 lines, 8 cpus, secure (IID 0200043b).
(XEN) softirq_handlers[4] set
(XEN) softirq_handlers[0] set
(XEN) softirq_handlers[1] set
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) softirq_handlers[3] set
(XEN) Allocated console ring of 32 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 00000002 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 00000003 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Populate P2M 0x80000000->0xa0000000 (1:1 mapping for dom0)
(XEN) Loading kernel from boot module 2
(XEN) Loading zImage from 0000000050000000 to 0000000087a00000-0000000087e78b68
(XEN) Loading dom0 DTB to 0x0000000088000000-0x00000000880067c9
(XEN) Scrubbing Free RAM: ...............done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Calling init_constructors
(XEN) Calling console_endboot
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Calling serial_endboot
(XEN) Calling domain_unpause_by_systemcontroller
(XEN) Calling switch_stack_and_jump
(XEN) Calling free_init_memory
(XEN) Freed 264kB init memory.
(XEN) Calling startup_cpu_idle_loop
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-15 14:44 ARM: EXYNOS 5410 - DOM0 not being scheduled Suriyan Ramasami
@ 2014-03-16 20:31 ` Julien Grall
2014-03-17 13:17 ` Suriyan Ramasami
2014-03-17 10:09 ` Ian Campbell
1 sibling, 1 reply; 19+ messages in thread
From: Julien Grall @ 2014-03-16 20:31 UTC (permalink / raw)
To: Suriyan Ramasami, xen-devel
On 15/03/14 14:44, Suriyan Ramasami wrote:
> Hello Friends,
Hello Suriyan,
Thank you for trying to boot Xen on new hardware!
> I have been trying to get DOM0 to run on XEN on teh odroid-xu
> (Exynos 5410). xen boots up in hyp mode. I can get all 4 CPU cores to
> come up. Confirmed that the Arch generic timer is ticking (note the
> output of the timer and the reread of the same timer for different
> values). Any pointers on where I should concentrate on to debug would
> be helpful. I do see that softirq_haldler[1] is never called which is
> the call to schedule().
Did you check that the timer interrupt is correctly fired and received
by Xen?
I advice you to restrict to 1 CPU for the first boot. You can do that by
removing every CPUs except the first one in the device tree.
> I am posting the full boot logs. Any help is appreciated.
Can you post the modification you made? (at least where does the print
come from).
> Thanks
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-15 14:44 ARM: EXYNOS 5410 - DOM0 not being scheduled Suriyan Ramasami
2014-03-16 20:31 ` Julien Grall
@ 2014-03-17 10:09 ` Ian Campbell
2014-03-17 13:24 ` Suriyan Ramasami
1 sibling, 1 reply; 19+ messages in thread
From: Ian Campbell @ 2014-03-17 10:09 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: xen-devel
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!
> 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.
Do you have any DEBUG_LL related config options enabled in your dom0
kernel?
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).
Hope that helps.
Ian.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-16 20:31 ` Julien Grall
@ 2014-03-17 13:17 ` Suriyan Ramasami
2014-03-17 13:21 ` Julien Grall
0 siblings, 1 reply; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-17 13:17 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel
On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>
> On 15/03/14 14:44, Suriyan Ramasami wrote:
>>
>> Hello Friends,
>
> Hello Suriyan,
>
> Thank you for trying to boot Xen on new hardware!
Thank you for the encouragement!
>
>
>> I have been trying to get DOM0 to run on XEN on teh odroid-xu
>> (Exynos 5410). xen boots up in hyp mode. I can get all 4 CPU cores to
>> come up. Confirmed that the Arch generic timer is ticking (note the
>> output of the timer and the reread of the same timer for different
>> values). Any pointers on where I should concentrate on to debug would
>> be helpful. I do see that softirq_haldler[1] is never called which is
>> the call to schedule().
>
>
> Did you check that the timer interrupt is correctly fired and received by
> Xen?
>
Any pointers in this area would be great. I shall explore this in parallel.
> I advice you to restrict to 1 CPU for the first boot. You can do that by
> removing every CPUs except the first one in the device tree.
>
OK, I did rerun with changing the dts to have a single CPU entry, with
same results.
>
>> I am posting the full boot logs. Any help is appreciated.
>
>
> Can you post the modification you made? (at least where does the print come
> from).
The boot_count print is coming from a mod in xen/arch/arm/time.c in
function init_xen_time()
- printk("boot_count: %llu reread: %llu\n", boot_count,
READ_SYSREG64(CNTPCT_EL0));
just before the function returns. The timer is started up in u-boot.
All the other printfs that you see with "Calling" is at the start of
the fucntions - I was trying to figure out if xen was hanging - this
is not the case though.
I shall reply further on Ian's email where I do see dom0 hanging in
calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
then loops in do_xor_speed() - specifically in the line while ((now =
jiffies) == j), which points to jiffies not getting incremented at
all!
Thanks so much!
- Suriyan
>
>> Thanks
>
>
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 13:17 ` Suriyan Ramasami
@ 2014-03-17 13:21 ` Julien Grall
2014-03-17 13:32 ` Suriyan Ramasami
0 siblings, 1 reply; 19+ messages in thread
From: Julien Grall @ 2014-03-17 13:21 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: Ian Campbell, xen-devel
Hello Suriyan,
On 03/17/2014 01:17 PM, Suriyan Ramasami wrote:
> On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>> Can you post the modification you made? (at least where does the print come
>> from).
> The boot_count print is coming from a mod in xen/arch/arm/time.c in
> function init_xen_time()
> - printk("boot_count: %llu reread: %llu\n", boot_count,
> READ_SYSREG64(CNTPCT_EL0));
> just before the function returns. The timer is started up in u-boot.
> All the other printfs that you see with "Calling" is at the start of
> the fucntions - I was trying to figure out if xen was hanging - this
> is not the case though.
>
> I shall reply further on Ian's email where I do see dom0 hanging in
> calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
> then loops in do_xor_speed() - specifically in the line while ((now =
> jiffies) == j), which points to jiffies not getting incremented at
> all!
I remembered to have the same issue with Arndale a while ago. Which
kernel are you using? Can you give the dom0 log?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 10:09 ` Ian Campbell
@ 2014-03-17 13:24 ` Suriyan Ramasami
2014-03-17 13:36 ` Ian Campbell
0 siblings, 1 reply; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-17 13:24 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel
On Mon, Mar 17, 2014 at 3:09 AM, Ian Campbell <Ian.Campbell@citrix.com> 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.
> 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)
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?
Thanks in advance for any advice!
- Suriyan
>
> Hope that helps.
>
> Ian.
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 13:21 ` Julien Grall
@ 2014-03-17 13:32 ` Suriyan Ramasami
2014-03-17 13:52 ` Julien Grall
0 siblings, 1 reply; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-17 13:32 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, xen-devel
On Mon, Mar 17, 2014 at 6:21 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hello Suriyan,
>
> On 03/17/2014 01:17 PM, Suriyan Ramasami wrote:
>> On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>>> Can you post the modification you made? (at least where does the print come
>>> from).
>> The boot_count print is coming from a mod in xen/arch/arm/time.c in
>> function init_xen_time()
>> - printk("boot_count: %llu reread: %llu\n", boot_count,
>> READ_SYSREG64(CNTPCT_EL0));
>> just before the function returns. The timer is started up in u-boot.
>> All the other printfs that you see with "Calling" is at the start of
>> the fucntions - I was trying to figure out if xen was hanging - this
>> is not the case though.
>>
>> I shall reply further on Ian's email where I do see dom0 hanging in
>> calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
>> then loops in do_xor_speed() - specifically in the line while ((now =
>> jiffies) == j), which points to jiffies not getting incremented at
>> all!
>
> I remembered to have the same issue with Arndale a while ago. Which
> kernel are you using? Can you give the dom0 log?
>
I am using linux kernel 3.13 which boots without xen. With xen, I do
not see any dom0 output (I even added the patch that you suggested in
http://lists.xen.org/archives/html/xen-devel/2013-04/msg02387.html) -
still no output from dom0.
I am pasting the linux output without xen, if that helps:
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.13.0+ (suriyan@Stealth) (gcc version
4.7.3 (Buildroot 2014.02) ) #3 Sun Mar 16 14:41:22 PDT 2014
[ 0.000000] Kernel was built at commit id 'aa5c722'
[ 0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=50c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] Machine model: Hardkernel odroid-xu board based on EXYNOS5410
[ 0.000000] NR_BANKS too low, ignoring high memory
[ 0.000000] cma: CMA: reserved 128 MiB at 67800000
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] CPU EXYNOS5410 (id 0xe5410023)
[ 0.000000] CPU: All CPU(s) started in HYP mode.
[ 0.000000] CPU: Virtualization extensions available.
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 520208
[ 0.000000] Kernel command line: console=hvc0,115200n8
root=/dev/mmcblk0p2 rw rootwait earlyprintk=xen led_blink=1
console=ttySAC2,115200n8
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 1930084K/2086912K available (4658K kernel code,
398K rwdata, 2224K rodata, 359K init, 472K bss, 156828K reserved,
1308672K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf800000 - 0xbfe00000 ( 6 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06c0c5c (6884 kB)
[ 0.000000] .init : 0xc06c1000 - 0xc071ae94 ( 360 kB)
[ 0.000000] .data : 0xc071c000 - 0xc077f8b8 ( 399 kB)
[ 0.000000] .bss : 0xc077f8b8 - 0xc07f5a08 ( 473 kB)
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] Architected cp15 timer(s) running at 24.00MHz (phys).
[ 0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
every 2863311519744ns
[ 0.000000] Switching to timer-based delay loop
[ 0.000000] Console: colour dummy device 80x30
[ 2919.828027] Calibrating delay loop (skipped), value calculated
using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[ 2919.828041] pid_max: default: 32768 minimum: 301
[ 2919.828129] Security Framework initialized
[ 2919.828155] AppArmor: AppArmor initialized
[ 2919.828184] Mount-cache hash table entries: 512
[ 2919.835306] CPU: Testing write buffer coherency: ok
[ 2919.835338] ftrace: allocating 24728 entries in 49 pages
[ 2919.863060] Setting up static identity map for 0x4045f968 - 0x4045f9b4
[ 2919.863997] devtmpfs: initialized
[ 2919.866378] VFP support v0.3: implementor 41 architecture 4 part 30
variant f rev 0
[ 2919.867338] xor: measuring software checksum speed
[ 2920.627630] arm4regs : 2025.600 MB/sec
[ 2920.677664] 8regs : 1593.600 MB/sec
[ 2920.727696] 32regs : 1184.800 MB/sec
[ 2920.727702] xor: using function: arm4regs (2025.600 MB/sec)
[ 2920.727709] pinctrl core: initialized pinctrl subsystem
[ 2920.728106] regulator-dummy: no parameters
[ 2920.732377] NET: Registered protocol family 16
[ 2920.733265] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 2920.734224] cpuidle: using governor ladder
[ 2920.734231] cpuidle: using governor menu
[ 2920.742777] hw-breakpoint: Failed to enable monitor mode on CPU 0.
[ 2920.742786] S3C Power Management, Copyright 2004 Simtec Electronics
[ 2920.742874] EXYNOS: PMU not supported
[ 2920.742880] EXYNOS: Initializing architecture
[ 2920.757481] bio: create slab <bio-0> at 0
[ 2920.838066] raid6: int32x1 197 MB/s
[ 2920.923019] raid6: int32x2 260 MB/s
[ 2921.008045] raid6: int32x4 316 MB/s
[ 2921.093125] raid6: int32x8 242 MB/s
[ 2921.093130] raid6: using algorithm int32x4 (316 MB/s)
[ 2921.093135] raid6: using intx1 recovery algorithm
[ 2921.093682] hdmi-en: 5000 mV
[ 2921.094703] SCSI subsystem initialized
[ 2921.095192] usbcore: registered new interface driver usbfs
[ 2921.095306] usbcore: registered new interface driver hub
[ 2921.095433] usbcore: registered new device driver usb
[ 2921.095919] s3c-i2c 12c70000.i2c: slave address 0x00
[ 2921.095930] s3c-i2c 12c70000.i2c: bus frequency set to 64 KHz
[ 2921.096349] s3c-i2c 12c70000.i2c: i2c-1: S3C I2C adapter
[ 2921.096430] s3c-i2c 12c80000.i2c: slave address 0x50
[ 2921.096440] s3c-i2c 12c80000.i2c: bus frequency set to 64 KHz
[ 2921.096818] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[ 2921.096876] s3c-i2c 12ce0000.i2c: slave address 0x00
[ 2921.096886] s3c-i2c 12ce0000.i2c: bus frequency set to 64 KHz
[ 2921.097033] s3c-i2c 12ce0000.i2c: i2c-8: S3C I2C adapter
[ 2921.097801] Advanced Linux Sound Architecture Driver Initialized.
[ 2921.098310] NetLabel: Initializing
[ 2921.098316] NetLabel: domain hash size = 128
[ 2921.098320] NetLabel: protocols = UNLABELED CIPSOv4
[ 2921.098362] NetLabel: unlabeled traffic allowed by default
[ 2921.098445] Switched to clocksource arch_sys_counter
[ 2921.110684] AppArmor: AppArmor Filesystem Enabled
[ 2921.121651] NET: Registered protocol family 2
[ 2921.121959] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 2921.122050] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[ 2921.122222] TCP: Hash tables configured (established 8192 bind 8192)
[ 2921.122280] TCP: reno registered
[ 2921.122289] UDP hash table entries: 512 (order: 2, 24576 bytes)
[ 2921.122327] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[ 2921.122474] NET: Registered protocol family 1
[ 2921.122656] RPC: Registered named UNIX socket transport module.
[ 2921.122662] RPC: Registered udp transport module.
[ 2921.122667] RPC: Registered tcp transport module.
[ 2921.122671] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2921.124118] audit: initializing netlink socket (disabled)
[ 2921.124140] type=2000 audit(0.545:1): initialized
[ 2921.125001] bounce pool size: 64 pages
[ 2921.125102] VFS: Disk quotas dquot_6.5.2
[ 2921.125131] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 2921.125535] NFS: Registering the id_resolver key type
[ 2921.125561] Key type id_resolver registered
[ 2921.125566] Key type id_legacy registered
[ 2921.125592] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
[ 2921.125915] bio: create slab <bio-1> at 1
[ 2921.126155] Btrfs loaded
[ 2921.126174] msgmni has been set to 1469
[ 2921.126794] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 253)
[ 2921.126802] io scheduler noop registered
[ 2921.126807] io scheduler deadline registered
[ 2921.126821] io scheduler cfq registered (default)
[ 2921.132060] xenfs: not registering filesystem on non-xen platform
[ 2921.200352] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 2921.201507] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 83,
base_baud = 0) is a S3C6400/10
[ 2921.201777] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 84,
base_baud = 0) is a S3C6400/10
[ 2921.202041] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 85,
base_baud = 0) is a S3C6400/10
[ 2921.850219] console [ttySAC2] enabled
[ 2921.854122] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 86,
base_baud = 0) is a S3C6400/10
[ 2921.863196] [drm] Initialized drm 1.1.0 20060810
[ 2921.867721] i2c i2c-2: attached exynos4210-hdmiddc into i2c adapter
successfully
[ 2921.875287] exynos-mixer 14450000.mixer: probe start
[ 2921.880834] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
[ 2921.887256] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2921.893145] [drm] No driver support for vblank timestamp query.
[ 2921.899480] [drm:exynos_drm_connector_get_modes] *ERROR* Panel
operation get_edid failed -19
[ 2921.907485] exynos-drm exynos-drm: No connectors reported connected
with modes
[ 2921.914653] [drm] Cannot find any crtc or sizes - going 1024x768
[ 2921.929017] Console: switching to colour frame buffer device 128x48
[ 2921.939056] exynos-drm exynos-drm: fb0: frame buffer device
[ 2921.944689] exynos-drm exynos-drm: registered panic notifier
[ 2921.950328] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[ 2921.961872] brd: module loaded
[ 2921.966418] loop: module loaded
[ 2921.968597] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2921.974743] usbcore: registered new interface driver asix
[ 2921.979985] usbcore: registered new interface driver ax88179_178a
[ 2921.986050] usbcore: registered new interface driver cdc_ether
[ 2921.991858] usbcore: registered new interface driver r815x
[ 2921.997322] usbcore: registered new interface driver dm9601
[ 2922.002871] usbcore: registered new interface driver net1080
[ 2922.008518] usbcore: registered new interface driver cdc_subset
[ 2922.014405] usbcore: registered new interface driver zaurus
[ 2922.019963] usbcore: registered new interface driver MOSCHIP
usb-ethernet driver
[ 2922.027349] usbcore: registered new interface driver cdc_ncm
[ 2922.033674] dwc3 12000000.dwc3: no usb2 phy configured
[ 2922.037982] platform 12000000.dwc3: Driver dwc3 requests probe deferral
[ 2922.045153] dwc3 12400000.dwc3: no usb2 phy configured
[ 2922.049697] platform 12400000.dwc3: Driver dwc3 requests probe deferral
[ 2922.056384] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2922.062784] ehci-exynos: EHCI EXYNOS driver
[ 2922.067019] unable to find transceiver of type USB2 PHY
[ 2922.072151] exynos-ehci 12110000.usb: no platform data or transceiver defined
[ 2922.079266] platform 12110000.usb: Driver exynos-ehci requests probe deferral
[ 2922.086476] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2922.092528] ohci-exynos: OHCI EXYNOS driver
[ 2922.096763] unable to find transceiver of type USB2 PHY
[ 2922.101899] exynos-ohci 12120000.usb: no platform data or transceiver defined
[ 2922.109011] platform 12120000.usb: Driver exynos-ohci requests probe deferral
[ 2922.116497] usbcore: registered new interface driver usb-storage
[ 2922.122244] samsung-usb2phy 12130000.usbphy: Not a multi controller PHY
[ 2922.128935] samsung-usb3phy 12100000.usbphy: Can't get usb-phy
sysreg cfg register
[ 2922.136306] samsung-usb3phy 12500000.usbphy: Can't get usb-phy
sysreg cfg register
[ 2922.144219] mousedev: PS/2 mouse device common for all mice
[ 2922.151001] max77xxx 4-0009: device found
[ 2922.154709] max77xxx 4-0009: no regulator-op-mode property property at LDO2
[ 2922.160774] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO9'
[ 2922.167577] max77xxx 4-0009: no regulator-op-mode property property at LDO18
[ 2922.174299] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO19'
[ 2922.181197] max77xxx 4-0009: no regulator-op-mode property property at LDO21
[ 2922.188179] max77xxx 4-0009: no regulator-op-mode property property at LDO23
[ 2922.195204] max77xxx 4-0009: no regulator-op-mode property property at LDO24
[ 2922.202227] max77xxx 4-0009: no regulator-op-mode property property at LDO25
[ 2922.209252] max77xxx 4-0009: no regulator-op-mode property property at LDO26
[ 2922.216269] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO27'
[ 2922.223119] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO28'
[ 2922.229970] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO29'
[ 2922.236830] max77xxx 4-0009: no regulator-op-mode property property at LDO30
[ 2922.243854] max77xxx 4-0009: no regulator-op-mode property property at LDO32
[ 2922.250870] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO33'
[ 2922.257720] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO34'
[ 2922.264572] max77xxx-pmic max77802-pmic: No matching regulator for 'LDO35'
[ 2922.271868] max77xxx 4-0009: no regulator-op-mode property property
at EN32KHZ_AP
[ 2922.278884] max77xxx 4-0009: no regulator-op-mode property property
at EN32KHZ_CP
[ 2922.286776] vdd_1v0: 1000 mV
[ 2922.289605] vdd_1v2: 1200 mV
[ 2922.292897] vdd_1v8_3: 1800 mV
[ 2922.296028] vdd_sd: 1800 <--> 3000 mV at 2800 mV
[ 2922.300709] vdd_1v8_5: 1800 mV
[ 2922.303620] vdd_1v8_6: 1800 mV
[ 2922.306729] vdd_1v8_7: 1800 mV
[ 2922.309725] vdd_ldo8: 1000 mV
[ 2922.312734] LDO9: at 1800 mV
[ 2922.315706] vdd_ldo10: 1800 mV
[ 2922.319197] vdd_ldo11: 1800 mV
[ 2922.322297] vdd_ldo12: 3000 mV
[ 2922.325432] vdd_ldo13: 1800 mV
[ 2922.328325] vdd_ldo14: 1800 mV
[ 2922.331672] vdd_ldo15: 1000 mV
[ 2922.334441] ldo_17: 1200 mV
[ 2922.337289] ldo_18: 1800 mV
[ 2922.340156] LDO19: at 1800 mV
[ 2922.343189] ldo_20: 1800 mV
[ 2922.346052] ldo_21: 2800 <--> 3300 mV at 2800 mV
[ 2922.351096] ldo_23: 3300 mV
[ 2922.353596] ldo_24: 2800 mV
[ 2922.356812] ldo_25: 3300 mV
[ 2922.359684] ldo_26: 3300 mV
[ 2922.362173] LDO27: at 1200 mV
[ 2922.365222] LDO28: at 1800 mV
[ 2922.368242] LDO29: at 1800 mV
[ 2922.371298] ldo_30: 1200 mV
[ 2922.374869] ldo_32: 3300 mV
[ 2922.377001] LDO33: at 2200 mV
[ 2922.380056] LDO34: at 3000 mV
[ 2922.383071] LDO35: at 1200 mV
[ 2922.386816] vdd_mif: 800 <--> 1300 mV at 1000 mV
[ 2922.391484] vdd_arm: 800 <--> 1500 mV at 1000 mV
[ 2922.396377] vdd_int: 800 <--> 1400 mV at 1000 mV
[ 2922.401057] vdd_g3d: 800 <--> 1400 mV at 1000 mV
[ 2922.405395] vdd_mem: 800 <--> 1500 mV at 1200 mV
[ 2922.410220] vdd_kfc: 800 <--> 1500 mV at 1000 mV
[ 2922.414390] vdd_1v35: 1350 mV
[ 2922.417777] vdd_emmc: 2850 mV
[ 2922.420457] vdd_2v: 2000 mV
[ 2922.423324] vdd_2v85: 2800 <--> 3000 mV at 2950 mV
[ 2922.428005] en32khz_ap: no parameters
[ 2922.431457] en32khz_cp: no parameters
[ 2922.435485] max77xxx-rtc max77802-rtc: max77xxx_rtc_probe
[ 2922.440325] max77xxx 4-0009: Failed to create debugfs directory
[ 2922.455248] max77xxx-rtc max77802-rtc: rtc core: registered
max77xxx-rtc as rtc0
[ 2922.463130] pro_id: 0xe5410023, lot_id: 0x4d054544
[ 2922.466445] Exynos5410 ASV : Lot ID is N62XG[Non Special]
[ 2922.471816] EXYNOS5410 ASV : Use Fusing Speed Group 5
[ 2922.476845] Exynos5410 ASV : invalid IDS value
[ 2922.481268] EXYNOS5410 ASV : N62XG IDS : 0 HPM : 0
[ 2922.486040] Registered asv member: VDD_ARM with group: 5
[ 2922.491157] Registered asv member: VDD_KFC with group: 5[
2922.496913] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30)
initialised: dm-devel@redhat.com
[ 2922.505094] Synopsys Designware Multimedia Card Interface Driver
[ 2922.511234] dwmmc_exynos 12200000.mmc: dummy supplies not allowed
[ 2922.516917] dwmmc_exynos 12200000.mmc: no vmmc regulator found: -19
[ 2922.523270] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[ 2922.529584] dwmmc_exynos 12200000.mmc: Version ID is 241a
[ 2922.535005] dwmmc_exynos 12200000.mmc: DW MMC controller at irq
107, 64 bit host data width, 128 deep fifo
[ 2922.573483] dwmmc_exynos 12200000.mmc: 1 slots initialized
[ 2922.577674] dwmmc_exynos 12220000.mmc: dummy supplies not allowed
[ 2922.583571] dwmmc_exynos 12220000.mmc: no vmmc regulator found: -19
[ 2922.589872] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[ 2922.596245] dwmmc_exynos 12220000.mmc: Version ID is 241a
[ 2922.601660] dwmmc_exynos 12220000.mmc: DW MMC controller at irq
109, 64 bit host data width, 128 deep fifo
[ 2922.638492] dwmmc_exynos 12220000.mmc: 1 slots initialized
[ 2922.642648] ledtrig-cpu: registered to indicate activity on CPUs
[ 2922.648823] usbcore: registered new interface driver usbhid
[ 2922.654040] usbhid: USB HID core driver
[ 2922.662337] oprofile: no performance counters
[ 2922.665450] oprofile: using timer interrupt.
[ 2922.669630] TCP: cubic registered
[ 2922.672754] Initializing XFRM netlink socket
[ 2922.677048] NET: Registered protocol family 10
[ 2922.681817] sit: IPv6 over IPv4 tunneling driver
[ 2922.686530] NET: Registered protocol family 17
[ 2922.690477] NET: Registered protocol family 15
[ 2922.694920] Key type dns_resolver registered
[ 2922.699210] Registering SWP/SWPB emulation handler
[ 2922.704186] power-domain: Power-off latency exceeded, new value 250291 ns
[ 2922.710914] AppArmor: AppArmor sha1 policy hashing enabled
[ 2922.919823] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller
[ 2922.923852] xhci-hcd xhci-hcd.4.auto: new USB bus registered,
assigned bus number 1
[ 2922.931745] xhci-hcd xhci-hcd.4.auto: irq 104, io mem 0x12000000
[ 2922.937587] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2922.944220] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 2922.951412] usb usb1: Product: xHCI Host Controller
[ 2922.956264] usb usb1: Manufacturer: Linux 3.13.0+ xhci-hcd
[ 2922.961727] usb usb1: SerialNumber: xhci-hcd.4.auto
[ 2922.967050] hub 1-0:1.0: USB hub found
[ 2922.970344] hub 1-0:1.0: 1 port detected
[ 2922.974402] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller
[ 2922.979690] xhci-hcd xhci-hcd.4.auto: new USB bus registered,
assigned bus number 2
[ 2922.987447] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 2922.994082] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 2923.001275] usb usb2: Product: xHCI Host Controller
[ 2923.006127] usb usb2: Manufacturer: Linux 3.13.0+ xhci-hcd
[ 2923.011589] usb usb2: SerialNumber: xhci-hcd.4.auto
[ 2923.016925] hub 2-0:1.0: USB hub found
[ 2923.020205] hub 2-0:1.0: 1 port detected
[ 2923.024426] samsung-usb2phy 12130000.usbphy: Already power on PHY
[ 2923.230387] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[ 2923.234417] xhci-hcd xhci-hcd.5.auto: new USB bus registered,
assigned bus number 3
[ 2923.242287] xhci-hcd xhci-hcd.5.auto: irq 232, io mem 0x12400000
[ 2923.248128] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[ 2923.254780] usb usb3: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 2923.261974] usb usb3: Product: xHCI Host Controller
[ 2923.266830] usb usb3: Manufacturer: Linux 3.13.0+ xhci-hcd
[ 2923.272293] usb usb3: SerialNumber: xhci-hcd.5.auto
[ 2923.277603] hub 3-0:1.0: USB hub found
[ 2923.280900] hub 3-0:1.0: 1 port detected
[ 2923.284957] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[ 2923.290256] xhci-hcd xhci-hcd.5.auto: new USB bus registered,
assigned bus number 4
[ 2923.298006] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[ 2923.304643] usb usb4: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 2923.311837] usb usb4: Product: xHCI Host Controller
[ 2923.316692] usb usb4: Manufacturer: Linux 3.13.0+ xhci-hcd
[ 2923.322158] usb usb4: SerialNumber: xhci-hcd.5.auto
[ 2923.327481] hub 4-0:1.0: USB hub found
[ 2923.330762] hub 4-0:1.0: 1 port detected
[ 2923.334920] samsung-usb2phy 12130000.usbphy: Already power on PHY
[ 2923.340719] exynos-ehci 12110000.usb: EHCI Host Controller
[ 2923.346188] exynos-ehci 12110000.usb: new USB bus registered,
assigned bus number 5
[ 2923.353909] exynos-ehci 12110000.usb: irq 103, io mem 0x12110000
[ 2923.368462] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[ 2923.373109] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
[ 2923.379769] usb usb5: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 2923.386956] usb usb5: Product: EHCI Host Controller
[ 2923.391809] usb usb5: Manufacturer: Linux 3.13.0+ ehci_hcd
[ 2923.397272] usb usb5: SerialNumber: 12110000.usb
[ 2923.401904] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot
req 50000000Hz, actual 50000000HZ div = 0)
[ 2923.412098] hub 5-0:1.0: USB hub found
[ 2923.415333] hub 5-0:1.0: 3 ports detected
[ 2923.419663] samsung-usb2phy 12130000.usbphy: Already power on PHY
[ 2923.425383] exynos-ohci 12120000.usb: USB Host Controller
[ 2923.430756] exynos-ohci 12120000.usb: new USB bus registered,
assigned bus number 6
[ 2923.438404] exynos-ohci 12120000.usb: irq 103, io mem 0x12120000
[ 2923.444417] mmc1: new high speed SDHC card at address e624
[ 2923.450080] isa bounce pool size: 16 pages
[ 2923.453944] mmcblk0: mmc1:e624 SU08G 7.40 GiB
[ 2923.459583] mmcblk0: p1 p2
[ 2923.502595] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[ 2923.507902] usb usb6: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 2923.515098] usb usb6: Product: USB Host Controller
[ 2923.519870] usb usb6: Manufacturer: Linux 3.13.0+ ohci_hcd
[ 2923.525330] usb usb6: SerialNumber: 12120000.usb
[ 2923.530391] hub 6-0:1.0: USB hub found
[ 2923.533676] hub 6-0:1.0: 3 ports detected
[ 2923.548205] usb3503 usb_hub.4: switched to HUB mode
[ 2923.551608] usb3503 usb_hub.4: usb3503_probe: probed in hub mode
[ 2923.559044] max77xxx-rtc max77802-rtc: setting system clock to
2000-01-01 01:01:41 UTC (946688501)
[ 2923.568976] ALSA device list:
[ 2923.570457] No soundcards found.
[ 2923.574596] EXT3-fs (mmcblk0p2): error: couldn't mount because of
unsupported optional features (240)
[ 2923.583533] EXT2-fs (mmcblk0p2): error: couldn't mount because of
unsupported optional features (240)
[ 2923.594332] EXT4-fs (mmcblk0p2): warning: mounting unchecked fs,
running e2fsck is recommended
[ 2923.612480] EXT4-fs (mmcblk0p2): mounted filesystem without
journal. Opts: (null)
[ 2923.618489] VFS: Mounted root (ext4 filesystem) on device 179:2.
[ 2923.638272] devtmpfs: mounted
[ 2923.639940] Freeing unused kernel memory: 356K (c06c1000 - c071a000)
[ 2923.743483] usb 5-2: new high-speed USB device number 2 using exynos-ehci
[ 2923.878985] usb 5-2: New USB device found, idVendor=0424, idProduct=9730
[ 2923.884288] usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2924.089197] random: init urandom read with 95 bits of entropy available
[ 2924.123490] usb 5-3: new high-speed USB device number 3 using exynos-ehci
[ 2924.258830] usb 5-3: New USB device found, idVendor=0424, idProduct=3503
[ 2924.264071] usb 5-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2924.276873] hub 5-3:1.0: USB hub found
[ 2924.279548] hub 5-3:1.0: 3 ports detected
[ 2924.373231] init: ureadahead main process (1147) terminated with status 5
[ 2924.696283] random: nonblocking pool is initialized
... etc...
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 13:24 ` Suriyan Ramasami
@ 2014-03-17 13:36 ` Ian Campbell
0 siblings, 0 replies; 19+ messages in thread
From: Ian Campbell @ 2014-03-17 13:36 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: xen-devel
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@citrix.com> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 13:32 ` Suriyan Ramasami
@ 2014-03-17 13:52 ` Julien Grall
2014-03-17 17:39 ` Suriyan Ramasami
0 siblings, 1 reply; 19+ messages in thread
From: Julien Grall @ 2014-03-17 13:52 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: Ian Campbell, xen-devel
On 03/17/2014 01:32 PM, Suriyan Ramasami wrote:
> On Mon, Mar 17, 2014 at 6:21 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> Hello Suriyan,
>>
>> On 03/17/2014 01:17 PM, Suriyan Ramasami wrote:
>>> On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>>>> Can you post the modification you made? (at least where does the print come
>>>> from).
>>> The boot_count print is coming from a mod in xen/arch/arm/time.c in
>>> function init_xen_time()
>>> - printk("boot_count: %llu reread: %llu\n", boot_count,
>>> READ_SYSREG64(CNTPCT_EL0));
>>> just before the function returns. The timer is started up in u-boot.
>>> All the other printfs that you see with "Calling" is at the start of
>>> the fucntions - I was trying to figure out if xen was hanging - this
>>> is not the case though.
>>>
>>> I shall reply further on Ian's email where I do see dom0 hanging in
>>> calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
>>> then loops in do_xor_speed() - specifically in the line while ((now =
>>> jiffies) == j), which points to jiffies not getting incremented at
>>> all!
>>
>> I remembered to have the same issue with Arndale a while ago. Which
>> kernel are you using? Can you give the dom0 log?
>>
> I am using linux kernel 3.13 which boots without xen. With xen, I do
By 3.13, you mean https://github.com/hardkernel/linux.git branch
odroid-3.13.y-linaro, right?
> not see any dom0 output (I even added the patch that you suggested in
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02387.html) -
> still no output from dom0.
> I am pasting the linux output without xen, if that helps:
Hmmm ... the exynos 5250 has it's own timer (samsung,exynos4210-mct)
which shouldn't be passthrough to dom0. I suspect that your issue come
from there.
Did you add specific platform code for the board? Can you uncomment
#define DEBUG_DT in xen/arch/arm/domain_build.c and paste the log on
pastebin?
Thanks,
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 13:52 ` Julien Grall
@ 2014-03-17 17:39 ` Suriyan Ramasami
2014-03-17 18:10 ` Suriyan Ramasami
0 siblings, 1 reply; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-17 17:39 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, xen-devel
On Mon, Mar 17, 2014 at 6:52 AM, Julien Grall <julien.grall@linaro.org> wrote:
> On 03/17/2014 01:32 PM, Suriyan Ramasami wrote:
>> On Mon, Mar 17, 2014 at 6:21 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>> Hello Suriyan,
>>>
>>> On 03/17/2014 01:17 PM, Suriyan Ramasami wrote:
>>>> On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>>>>> Can you post the modification you made? (at least where does the print come
>>>>> from).
>>>> The boot_count print is coming from a mod in xen/arch/arm/time.c in
>>>> function init_xen_time()
>>>> - printk("boot_count: %llu reread: %llu\n", boot_count,
>>>> READ_SYSREG64(CNTPCT_EL0));
>>>> just before the function returns. The timer is started up in u-boot.
>>>> All the other printfs that you see with "Calling" is at the start of
>>>> the fucntions - I was trying to figure out if xen was hanging - this
>>>> is not the case though.
>>>>
>>>> I shall reply further on Ian's email where I do see dom0 hanging in
>>>> calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
>>>> then loops in do_xor_speed() - specifically in the line while ((now =
>>>> jiffies) == j), which points to jiffies not getting incremented at
>>>> all!
>>>
>>> I remembered to have the same issue with Arndale a while ago. Which
>>> kernel are you using? Can you give the dom0 log?
>>>
>> I am using linux kernel 3.13 which boots without xen. With xen, I do
>
> By 3.13, you mean https://github.com/hardkernel/linux.git branch
> odroid-3.13.y-linaro, right?
Yes.
>
>> not see any dom0 output (I even added the patch that you suggested in
>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02387.html) -
>> still no output from dom0.
>
>> I am pasting the linux output without xen, if that helps:
>
> Hmmm ... the exynos 5250 has it's own timer (samsung,exynos4210-mct)
> which shouldn't be passthrough to dom0. I suspect that your issue come
> from there.
>
> Did you add specific platform code for the board? Can you uncomment
> #define DEBUG_DT in xen/arch/arm/domain_build.c and paste the log on
> pastebin?
>
Xen code changes:
1. I have modified xen/include/asm-arm/platforms/exynos5.h This will
be usefull when we kick the other CPUs.
/*#define S5P_PA_SYSRAM 0x02020000*/
#define S5P_PA_SYSRAM 0x0207301c
2. Also, xen/arch/arm/platform/exynos5.c
static const char * const exynos5_dt_compat[] __initconst =
{
"samsung,exynos5250",
"samsung,exynos5410",
NULL
};
3. As per your suggestion -> #define DEBUG_DT in xen/arch/arm/domain_build.c
In my previous emails I had mentioned the dom0 PC reflecting a hang in
xor or calibrate_loop(), which was without the above patches (I had a
xen compiled with the latest xen in git - 4.5 devel withouth the
exynos5410 related patches, hence the mct got passed to dom0, and as
you had earlier mentioned resulted in issues in dom0),
With the patches that I have mentioned above in xen 4.4 stable, I see
the dom0 PC in these functions:
The dts was patched as follows:
1. Add entry for timer: (copied from Arndale - I know frequency is
24M, but I have no idea about the other values)
timer {
compatible = "arm,cortex-a15-timer",
"arm,armv7-timer";
interrupts = <1 13 0xf08>,
<1 14 0xf08>,
<1 11 0xf08>,
<1 10 0xf08>;
clock-frequency = <24000000>;
};
2. Rename timer@101C0000 to mct@101C0000. It now looks like:
mct@101C0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101C0000 0xB00>;
... etc
Without the above renaming (timer@101C0000 to mct@101C0000), linux was
not booting on its own (without xen)
3. Comment out all the cpus except the first one. This is as per your
suggestion previously.
The dom0 kernel has the below XEN related configs: (enabled XEN and
Virtualisation)
[suriyan@Stealth linux-xu-3.13]$ grep XEN .config
CONFIG_XEN_DOM0=y
CONFIG_XEN=y
CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_XEN_BLKDEV_BACKEND is not set
CONFIG_XEN_NETDEV_FRONTEND=y
# CONFIG_XEN_NETDEV_BACKEND is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
4. Changed kernel/printk/printk.c - printk() to call xen_raw_console_write()
// r = vprintk_emit(0, -1, NULL, 0, fmt, args);
r = vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
xen_raw_console_write(buf);
return r;
With the above, I am pasting the full logs of boot. I pressed '0' to
get a few samples of what dom0 was doing.
a. (XEN) PC: c0053c88
c0053bc4 T ktime_get
c0053cc8 T pvclock_gtod_unregister_notifier
b. (XEN) PC: c00520e6
c00520a8 T rcu_irq_exit
c0052120 T rcu_irq_enter
c. (XEN) PC: c005555e
c00554f4 T get_xtime_and_monotonic_and_sleep_offset
c0055574 T ktime_get_update_offsets
d. (XEN) PC: c00472ce
c0047278 T do_raw_spin_unlock
c0047308 T do_raw_read_lock
e. (XEN) PC: c000843a
c000840c t gic_handle_irq
c0008464 T __exception_text_end
Full logs in http://pastebin.com/kF2EV6KH
Thanks so much!
- Suriyan
> Thanks,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 17:39 ` Suriyan Ramasami
@ 2014-03-17 18:10 ` Suriyan Ramasami
2014-03-17 18:22 ` Suriyan Ramasami
2014-03-17 22:03 ` Julien Grall
0 siblings, 2 replies; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-17 18:10 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, xen-devel
Hello Julien and Ian,
I at last got some output on the console (with some random first
characters), by doing the below change:
drivers/tty/hvc/hvc_xen.c:
- call dom0_write_console(0, str, len) directly.. ie, remove the if
(xen_domain()) condition. So, this is another issue, why is it not
recognized as a xen domain ?
With the above change, I can see the crash of dom0 as below! Have to
figure out why the architected timer frequency is not available in
dom0!
----------- dom0 output --------------
\x016Booting Linux on physical CPU 0x0
\x015Linux version 3.13.0+ (suriyan@Stealth) (gcc version 4.7.3
(Buildroot 2014.02) ) #2 SMP Mon Mar 17 11:02:36 PDT 2014
\x015Kernel was built at commit id 'aa5c722'
CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=50c5387d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
\x016Machine model: Hardkernel odroid-xu board based on EXYNOS5410
\x016cma: CMA: reserved 128 MiB at 98000000
\x016Memory policy: Data cache writealloc
CPU EXYNOS5410 (id 0xe5410023)
\x017On node 0 totalpages: 131072
\x017 Normal zone: 1024 pages used for memmap
\x017 Normal zone: 0 pages reserved
\x017 Normal zone: 131072 pages, LIFO batch:31
\x016PERCPU: Embedded 9 pages/cpu @c0c3d000 s15232 r8192 d13440 u36864
\x017pcpu-alloc: s15232 r8192 d13440 u36864 alloc=9*4096
\x017pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
\x015Kernel command line: console=hvc0 root=/dev/mmcblk0p2 rw rootwait
earlyprintk=xen
\x016PID hash table entries: 2048 (order: 1, 8192 bytes)
\x016Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
\x016Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 379932K/524288K available (4779K kernel code, 394K rwdata,
2252K rodata, 402K init, 497K bss, 144356K reserved, 0K highmem)
\x015Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf800000 - 0xbfe00000 ( 6 MB)
.text : 0xc0008000 - 0xc06e5ef4 (7032 kB)
.init : 0xc06e6000 - 0xc074ab80 ( 403 kB)
.data : 0xc074c000 - 0xc07ae8a0 ( 395 kB)
.bss : 0xc07ae8a0 - 0x\x016Hierarchical RCU implementation.
\x016 RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
\x016NR_IRQS:16 nr_irqs:16 16
\x014Architected timer frequency not available
Division by zero in kernel.
\x01dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0+ #2
[<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
(show_stack+0x11/0x14)
[<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
[<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
[<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c0058f65>]
(clockevents_config+0x1d/0x60)
[<c0058f65>] (clockevents_config+0x1d/0x60) from [<c0058fbb>]
(clockevents_config_and_register+0x13/0x1c)
[<c0058fbb>] (clockevents_config_and_register+0x13/0x1c) from
[<c038f1db>] (arch_timer_setup+0x67/0x124)
[<c038f1db>] (arch_timer_setup+0x67/0x124) from [<c070848d>]
(arch_timer_init+0xf5/0x160)
[<c070848d>] (arch_timer_init+0xf5/0x160) from [<c0707d21>]
(clocksource_of_init+0x25/0x40)
[<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
(start_kernel+0x187/0x310)
[<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
\x014------------[ cut here ]------------
\x014WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:44
cev_delta2ns+0xcd/0xe4()
\x01dModules linked in:
\x01dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0+ #2
[<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
(show_stack+0x11/0x14)
[<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
[<c0478d5f>] (dump_stack+0x4f/0x64) from [<c001c439>]
(warn_slowpath_common+0x51/0x70)
[<c001c439>] (warn_slowpath_common+0x51/0x70) from [<c001c46f>]
(warn_slowpath_null+0x17/0x1c)
[<c001c46f>] (warn_slowpath_null+0x17/0x1c) from [<c0058a91>]
(cev_delta2ns+0xcd/0xe4)
[<c0058a91>] (cev_delta2ns+0xcd/0xe4) from [<c0058f93>]
(clockevents_config+0x4b/0x60)
[<c0058f93>] (clockevents_config+0x4b/0x60) from [<c0058fbb>]
(clockevents_config_and_register+0x13/0x1c)
[<c0058fbb>] (clockevents_config_and_register+0x13/0x1c) from
[<c038f1db>] (arch_timer_setup+0x67/0x124)
[<c038f1db>] (arch_timer_setup+0x67/0x124) from [<c070848d>]
(arch_timer_init+0xf5/0x160)
[<c070848d>] (arch_timer_init+0xf5/0x160) from [<c0707d21>]
(clocksource_of_init+0x25/0x40)
[<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
(start_kernel+0x187/0x310)
[<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
\x014---[ end trace 15c15b4afa9eff8e ]---
\x016Architected cp15 timer(s) running at 0.00MHz (virt).
Division by zero in kernel.
\x01dCPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0+ #2
[<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
(show_stack+0x11/0x14)
[<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
[<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
[<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c0056625>]
(__clocksource_updatefreq_scale+0x35/0x158)
[<c0056625>] (__clocksource_updatefreq_scale+0x35/0x158) from
[<c0056757>] (__clocksource_register_scale+0xf/0x3c)
[<c0056757>] (__clocksource_register_scale+0xf/0x3c) from [<c070831f>]
(arch_timer_common_init+0xff/0x178)
[<c070831f>] (arch_timer_common_init+0xff/0x178) from [<c0707d21>]
(clocksource_of_init+0x25/0x40)
[<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
(start_kernel+0x187/0x310)
[<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
Division by zero in kernel.
\x01dCPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0+ #2
[<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
(show_stack+0x11/0x14)
[<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
[<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
[<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c00564d5>]
(clocks_calc_mult_shift+0x85/0xb8)
[<c00564d5>] (clocks_calc_mult_shift+0x85/0xb8) from [<c0056673>]
(__clocksource_updatefreq_scale+0x83/0x158)
[<c0056673>] (__clocksource_updatefreq_scale+0x83/0x158) from
[<c0056757>] (__clocksource_register_scale+0xf/0x3c)
[<c0056757>] (__clocksource_register_scale+0xf/0x3c) from [<c070831f>]
(arch_timer_common_init+0xff/0x178)
[<c070831f>] (arch_timer_common_init+0xff/0x178) from [<c0707d21>]
(clocksource_of_init+0x25/0x40)
[<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
(start_kernel+0x187/0x310)
[<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
Division by zero in kernel.
\x01dCPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0+ #2
[<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
(show_stack+0x11/0x14)
[<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
[<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
[<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c00564d5>]
(clocks_calc_mult_shift+0x85/0xb8)
[<c00564d5>] (clocks_calc_mult_shift+0x85/0xb8) from [<c06ef683>]
(sched_clock_register+0x7b/0x12c)
[<c06ef683>] (sched_clock_register+0x7b/0x12c) from [<c0708343>]
(arch_timer_common_init+0x123/0x178)
[<c0708343>] (arch_timer_common_init+0x123/0x178) from [<c0707d21>]
(clocksource_of_init+0x25/0x40)
[<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
(start_kernel+0x187/0x310)
[<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
\x016sched_clock: 56 bits at 0 Hz, resolution 0ns, wraps every 0ns
Thanks
- Suriyan
On Mon, Mar 17, 2014 at 10:39 AM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> On Mon, Mar 17, 2014 at 6:52 AM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 03/17/2014 01:32 PM, Suriyan Ramasami wrote:
>>> On Mon, Mar 17, 2014 at 6:21 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>>> Hello Suriyan,
>>>>
>>>> On 03/17/2014 01:17 PM, Suriyan Ramasami wrote:
>>>>> On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>>>>>> Can you post the modification you made? (at least where does the print come
>>>>>> from).
>>>>> The boot_count print is coming from a mod in xen/arch/arm/time.c in
>>>>> function init_xen_time()
>>>>> - printk("boot_count: %llu reread: %llu\n", boot_count,
>>>>> READ_SYSREG64(CNTPCT_EL0));
>>>>> just before the function returns. The timer is started up in u-boot.
>>>>> All the other printfs that you see with "Calling" is at the start of
>>>>> the fucntions - I was trying to figure out if xen was hanging - this
>>>>> is not the case though.
>>>>>
>>>>> I shall reply further on Ian's email where I do see dom0 hanging in
>>>>> calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
>>>>> then loops in do_xor_speed() - specifically in the line while ((now =
>>>>> jiffies) == j), which points to jiffies not getting incremented at
>>>>> all!
>>>>
>>>> I remembered to have the same issue with Arndale a while ago. Which
>>>> kernel are you using? Can you give the dom0 log?
>>>>
>>> I am using linux kernel 3.13 which boots without xen. With xen, I do
>>
>> By 3.13, you mean https://github.com/hardkernel/linux.git branch
>> odroid-3.13.y-linaro, right?
> Yes.
>>
>>> not see any dom0 output (I even added the patch that you suggested in
>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02387.html) -
>>> still no output from dom0.
>>
>>> I am pasting the linux output without xen, if that helps:
>>
>> Hmmm ... the exynos 5250 has it's own timer (samsung,exynos4210-mct)
>> which shouldn't be passthrough to dom0. I suspect that your issue come
>> from there.
>>
>> Did you add specific platform code for the board? Can you uncomment
>> #define DEBUG_DT in xen/arch/arm/domain_build.c and paste the log on
>> pastebin?
>>
>
> Xen code changes:
>
> 1. I have modified xen/include/asm-arm/platforms/exynos5.h This will
> be usefull when we kick the other CPUs.
> /*#define S5P_PA_SYSRAM 0x02020000*/
> #define S5P_PA_SYSRAM 0x0207301c
>
> 2. Also, xen/arch/arm/platform/exynos5.c
> static const char * const exynos5_dt_compat[] __initconst =
> {
> "samsung,exynos5250",
> "samsung,exynos5410",
> NULL
> };
>
> 3. As per your suggestion -> #define DEBUG_DT in xen/arch/arm/domain_build.c
>
> In my previous emails I had mentioned the dom0 PC reflecting a hang in
> xor or calibrate_loop(), which was without the above patches (I had a
> xen compiled with the latest xen in git - 4.5 devel withouth the
> exynos5410 related patches, hence the mct got passed to dom0, and as
> you had earlier mentioned resulted in issues in dom0),
>
> With the patches that I have mentioned above in xen 4.4 stable, I see
> the dom0 PC in these functions:
>
> The dts was patched as follows:
> 1. Add entry for timer: (copied from Arndale - I know frequency is
> 24M, but I have no idea about the other values)
> timer {
> compatible = "arm,cortex-a15-timer",
> "arm,armv7-timer";
> interrupts = <1 13 0xf08>,
> <1 14 0xf08>,
> <1 11 0xf08>,
> <1 10 0xf08>;
> clock-frequency = <24000000>;
> };
>
> 2. Rename timer@101C0000 to mct@101C0000. It now looks like:
> mct@101C0000 {
> compatible = "samsung,exynos4210-mct";
> reg = <0x101C0000 0xB00>;
> ... etc
>
> Without the above renaming (timer@101C0000 to mct@101C0000), linux was
> not booting on its own (without xen)
>
> 3. Comment out all the cpus except the first one. This is as per your
> suggestion previously.
>
> The dom0 kernel has the below XEN related configs: (enabled XEN and
> Virtualisation)
> [suriyan@Stealth linux-xu-3.13]$ grep XEN .config
> CONFIG_XEN_DOM0=y
> CONFIG_XEN=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> # CONFIG_XEN_BLKDEV_BACKEND is not set
> CONFIG_XEN_NETDEV_FRONTEND=y
> # CONFIG_XEN_NETDEV_BACKEND is not set
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> CONFIG_HVC_XEN_FRONTEND=y
> CONFIG_XEN_FBDEV_FRONTEND=y
> CONFIG_XEN_DEV_EVTCHN=y
> CONFIG_XEN_BACKEND=y
> CONFIG_XENFS=y
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=m
> CONFIG_XEN_GRANT_DEV_ALLOC=m
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_PRIVCMD=y
>
> 4. Changed kernel/printk/printk.c - printk() to call xen_raw_console_write()
> // r = vprintk_emit(0, -1, NULL, 0, fmt, args);
> r = vsnprintf(buf, sizeof(buf), fmt, args);
> va_end(args);
>
> xen_raw_console_write(buf);
> return r;
>
>
> With the above, I am pasting the full logs of boot. I pressed '0' to
> get a few samples of what dom0 was doing.
> a. (XEN) PC: c0053c88
> c0053bc4 T ktime_get
> c0053cc8 T pvclock_gtod_unregister_notifier
>
> b. (XEN) PC: c00520e6
> c00520a8 T rcu_irq_exit
> c0052120 T rcu_irq_enter
>
> c. (XEN) PC: c005555e
> c00554f4 T get_xtime_and_monotonic_and_sleep_offset
> c0055574 T ktime_get_update_offsets
>
> d. (XEN) PC: c00472ce
> c0047278 T do_raw_spin_unlock
> c0047308 T do_raw_read_lock
>
> e. (XEN) PC: c000843a
> c000840c t gic_handle_irq
> c0008464 T __exception_text_end
>
> Full logs in http://pastebin.com/kF2EV6KH
>
> Thanks so much!
> - Suriyan
>
>
>
>> Thanks,
>>
>> --
>> Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 18:10 ` Suriyan Ramasami
@ 2014-03-17 18:22 ` Suriyan Ramasami
2014-03-17 22:15 ` Julien Grall
2014-03-17 22:03 ` Julien Grall
1 sibling, 1 reply; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-17 18:22 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, xen-devel
Hello Julien and Ian,
You can tell that I am just so excited! So, I did get dom0 to run now!
For the moment I just hardcoded arch_timer_rate to 24000000 in
drivers/clocksource/arm_arch_timer.c and dom0 boots up!
So, now it remains, what is the right way to do the correction:
1. no dom0 output
2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining
clock-frequency.
I shall continue to pursure this further, but would like your inputs
on the above two points.
Thanks
- Suriyan
On Mon, Mar 17, 2014 at 11:10 AM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> Hello Julien and Ian,
> I at last got some output on the console (with some random first
> characters), by doing the below change:
> drivers/tty/hvc/hvc_xen.c:
> - call dom0_write_console(0, str, len) directly.. ie, remove the if
> (xen_domain()) condition. So, this is another issue, why is it not
> recognized as a xen domain ?
>
> With the above change, I can see the crash of dom0 as below! Have to
> figure out why the architected timer frequency is not available in
> dom0!
>
> ----------- dom0 output --------------
> 6Booting Linux on physical CPU 0x0
> 5Linux version 3.13.0+ (suriyan@Stealth) (gcc version 4.7.3
> (Buildroot 2014.02) ) #2 SMP Mon Mar 17 11:02:36 PDT 2014
> 5Kernel was built at commit id 'aa5c722'
> CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=50c5387d
> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> 6Machine model: Hardkernel odroid-xu board based on EXYNOS5410
> 6cma: CMA: reserved 128 MiB at 98000000
> 6Memory policy: Data cache writealloc
> CPU EXYNOS5410 (id 0xe5410023)
> 7On node 0 totalpages: 131072
> 7 Normal zone: 1024 pages used for memmap
> 7 Normal zone: 0 pages reserved
> 7 Normal zone: 131072 pages, LIFO batch:31
> 6PERCPU: Embedded 9 pages/cpu @c0c3d000 s15232 r8192 d13440 u36864
> 7pcpu-alloc: s15232 r8192 d13440 u36864 alloc=9*4096
> 7pcpu-alloc: [0] 0
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
> 5Kernel command line: console=hvc0 root=/dev/mmcblk0p2 rw rootwait
> earlyprintk=xen
> 6PID hash table entries: 2048 (order: 1, 8192 bytes)
> 6Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> 6Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 379932K/524288K available (4779K kernel code, 394K rwdata,
> 2252K rodata, 402K init, 497K bss, 144356K reserved, 0K highmem)
> 5Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
> lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> modules : 0xbf800000 - 0xbfe00000 ( 6 MB)
> .text : 0xc0008000 - 0xc06e5ef4 (7032 kB)
> .init : 0xc06e6000 - 0xc074ab80 ( 403 kB)
> .data : 0xc074c000 - 0xc07ae8a0 ( 395 kB)
> .bss : 0xc07ae8a0 - 0x 6Hierarchical RCU implementation.
> 6 RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
> 6NR_IRQS:16 nr_irqs:16 16
> 4Architected timer frequency not available
> Division by zero in kernel.
> dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0+ #2
> [<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
> (show_stack+0x11/0x14)
> [<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
> [<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
> [<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c0058f65>]
> (clockevents_config+0x1d/0x60)
> [<c0058f65>] (clockevents_config+0x1d/0x60) from [<c0058fbb>]
> (clockevents_config_and_register+0x13/0x1c)
> [<c0058fbb>] (clockevents_config_and_register+0x13/0x1c) from
> [<c038f1db>] (arch_timer_setup+0x67/0x124)
> [<c038f1db>] (arch_timer_setup+0x67/0x124) from [<c070848d>]
> (arch_timer_init+0xf5/0x160)
> [<c070848d>] (arch_timer_init+0xf5/0x160) from [<c0707d21>]
> (clocksource_of_init+0x25/0x40)
> [<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
> (start_kernel+0x187/0x310)
> [<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
> 4------------[ cut here ]------------
> 4WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:44
> cev_delta2ns+0xcd/0xe4()
> dModules linked in:
> dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0+ #2
> [<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
> (show_stack+0x11/0x14)
> [<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
> [<c0478d5f>] (dump_stack+0x4f/0x64) from [<c001c439>]
> (warn_slowpath_common+0x51/0x70)
> [<c001c439>] (warn_slowpath_common+0x51/0x70) from [<c001c46f>]
> (warn_slowpath_null+0x17/0x1c)
> [<c001c46f>] (warn_slowpath_null+0x17/0x1c) from [<c0058a91>]
> (cev_delta2ns+0xcd/0xe4)
> [<c0058a91>] (cev_delta2ns+0xcd/0xe4) from [<c0058f93>]
> (clockevents_config+0x4b/0x60)
> [<c0058f93>] (clockevents_config+0x4b/0x60) from [<c0058fbb>]
> (clockevents_config_and_register+0x13/0x1c)
> [<c0058fbb>] (clockevents_config_and_register+0x13/0x1c) from
> [<c038f1db>] (arch_timer_setup+0x67/0x124)
> [<c038f1db>] (arch_timer_setup+0x67/0x124) from [<c070848d>]
> (arch_timer_init+0xf5/0x160)
> [<c070848d>] (arch_timer_init+0xf5/0x160) from [<c0707d21>]
> (clocksource_of_init+0x25/0x40)
> [<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
> (start_kernel+0x187/0x310)
> [<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
> 4---[ end trace 15c15b4afa9eff8e ]---
> 6Architected cp15 timer(s) running at 0.00MHz (virt).
> Division by zero in kernel.
> dCPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0+ #2
> [<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
> (show_stack+0x11/0x14)
> [<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
> [<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
> [<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c0056625>]
> (__clocksource_updatefreq_scale+0x35/0x158)
> [<c0056625>] (__clocksource_updatefreq_scale+0x35/0x158) from
> [<c0056757>] (__clocksource_register_scale+0xf/0x3c)
> [<c0056757>] (__clocksource_register_scale+0xf/0x3c) from [<c070831f>]
> (arch_timer_common_init+0xff/0x178)
> [<c070831f>] (arch_timer_common_init+0xff/0x178) from [<c0707d21>]
> (clocksource_of_init+0x25/0x40)
> [<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
> (start_kernel+0x187/0x310)
> [<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
> Division by zero in kernel.
> dCPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0+ #2
> [<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
> (show_stack+0x11/0x14)
> [<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
> [<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
> [<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c00564d5>]
> (clocks_calc_mult_shift+0x85/0xb8)
> [<c00564d5>] (clocks_calc_mult_shift+0x85/0xb8) from [<c0056673>]
> (__clocksource_updatefreq_scale+0x83/0x158)
> [<c0056673>] (__clocksource_updatefreq_scale+0x83/0x158) from
> [<c0056757>] (__clocksource_register_scale+0xf/0x3c)
> [<c0056757>] (__clocksource_register_scale+0xf/0x3c) from [<c070831f>]
> (arch_timer_common_init+0xff/0x178)
> [<c070831f>] (arch_timer_common_init+0xff/0x178) from [<c0707d21>]
> (clocksource_of_init+0x25/0x40)
> [<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
> (start_kernel+0x187/0x310)
> [<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
> Division by zero in kernel.
> dCPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0+ #2
> [<c0012315>] (unwind_backtrace+0x1/0x9c) from [<c000fbf1>]
> (show_stack+0x11/0x14)
> [<c000fbf1>] (show_stack+0x11/0x14) from [<c0478d5f>] (dump_stack+0x4f/0x64)
> [<c0478d5f>] (dump_stack+0x4f/0x64) from [<c025ee7f>] (Ldiv0_64+0x9/0x1a)
> [<c025ee7f>] (Ldiv0_64+0x9/0x1a) from [<c00564d5>]
> (clocks_calc_mult_shift+0x85/0xb8)
> [<c00564d5>] (clocks_calc_mult_shift+0x85/0xb8) from [<c06ef683>]
> (sched_clock_register+0x7b/0x12c)
> [<c06ef683>] (sched_clock_register+0x7b/0x12c) from [<c0708343>]
> (arch_timer_common_init+0x123/0x178)
> [<c0708343>] (arch_timer_common_init+0x123/0x178) from [<c0707d21>]
> (clocksource_of_init+0x25/0x40)
> [<c0707d21>] (clocksource_of_init+0x25/0x40) from [<c06e67bb>]
> (start_kernel+0x187/0x310)
> [<c06e67bb>] (start_kernel+0x187/0x310) from [<8000807d>] (0x8000807d)
> 6sched_clock: 56 bits at 0 Hz, resolution 0ns, wraps every 0ns
>
> Thanks
> - Suriyan
>
>
>
>
>
>
> On Mon, Mar 17, 2014 at 10:39 AM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
>> On Mon, Mar 17, 2014 at 6:52 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>> On 03/17/2014 01:32 PM, Suriyan Ramasami wrote:
>>>> On Mon, Mar 17, 2014 at 6:21 AM, Julien Grall <julien.grall@linaro.org> wrote:
>>>>> Hello Suriyan,
>>>>>
>>>>> On 03/17/2014 01:17 PM, Suriyan Ramasami wrote:
>>>>>> On Sun, Mar 16, 2014 at 1:31 PM, Julien Grall <julien.grall@citrix.com> wrote:
>>>>>>> Can you post the modification you made? (at least where does the print come
>>>>>>> from).
>>>>>> The boot_count print is coming from a mod in xen/arch/arm/time.c in
>>>>>> function init_xen_time()
>>>>>> - printk("boot_count: %llu reread: %llu\n", boot_count,
>>>>>> READ_SYSREG64(CNTPCT_EL0));
>>>>>> just before the function returns. The timer is started up in u-boot.
>>>>>> All the other printfs that you see with "Calling" is at the start of
>>>>>> the fucntions - I was trying to figure out if xen was hanging - this
>>>>>> is not the case though.
>>>>>>
>>>>>> I shall reply further on Ian's email where I do see dom0 hanging in
>>>>>> calibrate_delay(). If I pass lpj=4464640 in the kernel parameters, it
>>>>>> then loops in do_xor_speed() - specifically in the line while ((now =
>>>>>> jiffies) == j), which points to jiffies not getting incremented at
>>>>>> all!
>>>>>
>>>>> I remembered to have the same issue with Arndale a while ago. Which
>>>>> kernel are you using? Can you give the dom0 log?
>>>>>
>>>> I am using linux kernel 3.13 which boots without xen. With xen, I do
>>>
>>> By 3.13, you mean https://github.com/hardkernel/linux.git branch
>>> odroid-3.13.y-linaro, right?
>> Yes.
>>>
>>>> not see any dom0 output (I even added the patch that you suggested in
>>>> http://lists.xen.org/archives/html/xen-devel/2013-04/msg02387.html) -
>>>> still no output from dom0.
>>>
>>>> I am pasting the linux output without xen, if that helps:
>>>
>>> Hmmm ... the exynos 5250 has it's own timer (samsung,exynos4210-mct)
>>> which shouldn't be passthrough to dom0. I suspect that your issue come
>>> from there.
>>>
>>> Did you add specific platform code for the board? Can you uncomment
>>> #define DEBUG_DT in xen/arch/arm/domain_build.c and paste the log on
>>> pastebin?
>>>
>>
>> Xen code changes:
>>
>> 1. I have modified xen/include/asm-arm/platforms/exynos5.h This will
>> be usefull when we kick the other CPUs.
>> /*#define S5P_PA_SYSRAM 0x02020000*/
>> #define S5P_PA_SYSRAM 0x0207301c
>>
>> 2. Also, xen/arch/arm/platform/exynos5.c
>> static const char * const exynos5_dt_compat[] __initconst =
>> {
>> "samsung,exynos5250",
>> "samsung,exynos5410",
>> NULL
>> };
>>
>> 3. As per your suggestion -> #define DEBUG_DT in xen/arch/arm/domain_build.c
>>
>> In my previous emails I had mentioned the dom0 PC reflecting a hang in
>> xor or calibrate_loop(), which was without the above patches (I had a
>> xen compiled with the latest xen in git - 4.5 devel withouth the
>> exynos5410 related patches, hence the mct got passed to dom0, and as
>> you had earlier mentioned resulted in issues in dom0),
>>
>> With the patches that I have mentioned above in xen 4.4 stable, I see
>> the dom0 PC in these functions:
>>
>> The dts was patched as follows:
>> 1. Add entry for timer: (copied from Arndale - I know frequency is
>> 24M, but I have no idea about the other values)
>> timer {
>> compatible = "arm,cortex-a15-timer",
>> "arm,armv7-timer";
>> interrupts = <1 13 0xf08>,
>> <1 14 0xf08>,
>> <1 11 0xf08>,
>> <1 10 0xf08>;
>> clock-frequency = <24000000>;
>> };
>>
>> 2. Rename timer@101C0000 to mct@101C0000. It now looks like:
>> mct@101C0000 {
>> compatible = "samsung,exynos4210-mct";
>> reg = <0x101C0000 0xB00>;
>> ... etc
>>
>> Without the above renaming (timer@101C0000 to mct@101C0000), linux was
>> not booting on its own (without xen)
>>
>> 3. Comment out all the cpus except the first one. This is as per your
>> suggestion previously.
>>
>> The dom0 kernel has the below XEN related configs: (enabled XEN and
>> Virtualisation)
>> [suriyan@Stealth linux-xu-3.13]$ grep XEN .config
>> CONFIG_XEN_DOM0=y
>> CONFIG_XEN=y
>> CONFIG_XEN_BLKDEV_FRONTEND=y
>> # CONFIG_XEN_BLKDEV_BACKEND is not set
>> CONFIG_XEN_NETDEV_FRONTEND=y
>> # CONFIG_XEN_NETDEV_BACKEND is not set
>> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
>> CONFIG_HVC_XEN=y
>> CONFIG_HVC_XEN_FRONTEND=y
>> CONFIG_XEN_FBDEV_FRONTEND=y
>> CONFIG_XEN_DEV_EVTCHN=y
>> CONFIG_XEN_BACKEND=y
>> CONFIG_XENFS=y
>> CONFIG_XEN_COMPAT_XENFS=y
>> CONFIG_XEN_SYS_HYPERVISOR=y
>> CONFIG_XEN_XENBUS_FRONTEND=y
>> CONFIG_XEN_GNTDEV=m
>> CONFIG_XEN_GRANT_DEV_ALLOC=m
>> CONFIG_SWIOTLB_XEN=y
>> CONFIG_XEN_PRIVCMD=y
>>
>> 4. Changed kernel/printk/printk.c - printk() to call xen_raw_console_write()
>> // r = vprintk_emit(0, -1, NULL, 0, fmt, args);
>> r = vsnprintf(buf, sizeof(buf), fmt, args);
>> va_end(args);
>>
>> xen_raw_console_write(buf);
>> return r;
>>
>>
>> With the above, I am pasting the full logs of boot. I pressed '0' to
>> get a few samples of what dom0 was doing.
>> a. (XEN) PC: c0053c88
>> c0053bc4 T ktime_get
>> c0053cc8 T pvclock_gtod_unregister_notifier
>>
>> b. (XEN) PC: c00520e6
>> c00520a8 T rcu_irq_exit
>> c0052120 T rcu_irq_enter
>>
>> c. (XEN) PC: c005555e
>> c00554f4 T get_xtime_and_monotonic_and_sleep_offset
>> c0055574 T ktime_get_update_offsets
>>
>> d. (XEN) PC: c00472ce
>> c0047278 T do_raw_spin_unlock
>> c0047308 T do_raw_read_lock
>>
>> e. (XEN) PC: c000843a
>> c000840c t gic_handle_irq
>> c0008464 T __exception_text_end
>>
>> Full logs in http://pastebin.com/kF2EV6KH
>>
>> Thanks so much!
>> - Suriyan
>>
>>
>>
>>> Thanks,
>>>
>>> --
>>> Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 18:10 ` Suriyan Ramasami
2014-03-17 18:22 ` Suriyan Ramasami
@ 2014-03-17 22:03 ` Julien Grall
1 sibling, 0 replies; 19+ messages in thread
From: Julien Grall @ 2014-03-17 22:03 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: Ian Campbell, xen-devel
Hello Suriyan,
On 17/03/14 18:10, Suriyan Ramasami wrote:
> Hello Julien and Ian,
> I at last got some output on the console (with some random first
> characters), by doing the below change:
> drivers/tty/hvc/hvc_xen.c:
> - call dom0_write_console(0, str, len) directly.. ie, remove the if
> (xen_domain()) condition. So, this is another issue, why is it not
> recognized as a xen domain ?
xen_domain() is correctly set quite late on ARM. I have already pointed
out this issue when the patch to modify xen_raw_console_write was sent
on the mailing (see https://lkml.org/lkml/2013/10/24/343). But, it seems
that my comment was not considered when the patch was pushed.
Ian Campbell has offered a solution here:
https://lkml.org/lkml/2013/10/26/21, but I never had the time to send it.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 18:22 ` Suriyan Ramasami
@ 2014-03-17 22:15 ` Julien Grall
2014-03-18 9:52 ` Ian Campbell
0 siblings, 1 reply; 19+ messages in thread
From: Julien Grall @ 2014-03-17 22:15 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: Ian Campbell, xen-devel
On 17/03/14 18:22, Suriyan Ramasami wrote:
> Hello Julien and Ian,
Hello Suriyan,
> You can tell that I am just so excited! So, I did get dom0 to run now!
great ! Thank you for the log and dig into this issue.
> For the moment I just hardcoded arch_timer_rate to 24000000 in
> drivers/clocksource/arm_arch_timer.c and dom0 boots up!
I'm not sure what you meant by hardcoding, how did you do it?
> So, now it remains, what is the right way to do the correction:
> 1. no dom0 output
Already answer to it on a previous mail :).
> 2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining
> clock-frequency.
The clock-frequency properties is not given to dom0. It should be able
to retrieve the frequency from the timer (CNTFRQ). That would mean that
u-boot is not correctly set up the frequency (it's the only one able to
do it as it need to be done in secure world).
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-17 22:15 ` Julien Grall
@ 2014-03-18 9:52 ` Ian Campbell
2014-03-18 12:04 ` Julien Grall
0 siblings, 1 reply; 19+ messages in thread
From: Ian Campbell @ 2014-03-18 9:52 UTC (permalink / raw)
To: Julien Grall; +Cc: Suriyan Ramasami, xen-devel
On Mon, 2014-03-17 at 22:15 +0000, Julien Grall wrote:
> > 2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining
> > clock-frequency.
>
> The clock-frequency properties is not given to dom0. It should be able
> to retrieve the frequency from the timer (CNTFRQ). That would mean that
> u-boot is not correctly set up the frequency (it's the only one able to
> do it as it need to be done in secure world).
If the clock-frequency property is present in the host DT then that
would imply that secure world is not setting CNTFRQ or is setting it
wrong (since the property is effectively a workaround for that exact
bug). Perhaps we should propagate it if it is present?
Perhaps make_timer_node should insert the property iff the host dt has
it? Will one of you role a patch? (Suriyan, see
http://wiki.xen.org/wiki/Submitting_Xen_Patches for advice if you device
to do it).
While grepping about this I noticed that make_timer_node doesn't use
DT_MATCH_TIMER, which I guess is just an accidental oversight, perhaps
if someone is fixing the clock-frequency issue they could throw in a
second patch for this too?
Ian.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-18 9:52 ` Ian Campbell
@ 2014-03-18 12:04 ` Julien Grall
2014-03-18 13:37 ` Ian Campbell
0 siblings, 1 reply; 19+ messages in thread
From: Julien Grall @ 2014-03-18 12:04 UTC (permalink / raw)
To: Ian Campbell; +Cc: Suriyan Ramasami, xen-devel
Hi Ian,
On 03/18/2014 09:52 AM, Ian Campbell wrote:
> On Mon, 2014-03-17 at 22:15 +0000, Julien Grall wrote:
>>> 2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining
>>> clock-frequency.
>>
>> The clock-frequency properties is not given to dom0. It should be able
>> to retrieve the frequency from the timer (CNTFRQ). That would mean that
>> u-boot is not correctly set up the frequency (it's the only one able to
>> do it as it need to be done in secure world).
>
> If the clock-frequency property is present in the host DT then that
> would imply that secure world is not setting CNTFRQ or is setting it
> wrong (since the property is effectively a workaround for that exact
> bug). Perhaps we should propagate it if it is present?
It's easy to do it for dom0, what about guests? I think it would be
better to let the bootloader to set up the frequency. I'm a bit
surprised that it's not already the case for this board.
For instance, on the Arndale the property "clock-frequency" exists but
CNTFRQ is also correctly set.
> While grepping about this I noticed that make_timer_node doesn't use
> DT_MATCH_TIMER, which I guess is just an accidental oversight, perhaps
> if someone is fixing the clock-frequency issue they could throw in a
> second patch for this too?
I think it's an error during the cleanup.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-18 12:04 ` Julien Grall
@ 2014-03-18 13:37 ` Ian Campbell
2014-03-18 15:41 ` Suriyan Ramasami
0 siblings, 1 reply; 19+ messages in thread
From: Ian Campbell @ 2014-03-18 13:37 UTC (permalink / raw)
To: Julien Grall; +Cc: Suriyan Ramasami, xen-devel
On Tue, 2014-03-18 at 12:04 +0000, Julien Grall wrote:
> Hi Ian,
>
> On 03/18/2014 09:52 AM, Ian Campbell wrote:
> > On Mon, 2014-03-17 at 22:15 +0000, Julien Grall wrote:
> >>> 2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining
> >>> clock-frequency.
> >>
> >> The clock-frequency properties is not given to dom0. It should be able
> >> to retrieve the frequency from the timer (CNTFRQ). That would mean that
> >> u-boot is not correctly set up the frequency (it's the only one able to
> >> do it as it need to be done in secure world).
> >
> > If the clock-frequency property is present in the host DT then that
> > would imply that secure world is not setting CNTFRQ or is setting it
> > wrong (since the property is effectively a workaround for that exact
> > bug). Perhaps we should propagate it if it is present?
>
> It's easy to do it for dom0, what about guests? I think it would be
> better to let the bootloader to set up the frequency. I'm a bit
> surprised that it's not already the case for this board.
Well, that's the issue -- sometimes we just need to deal with what the
hardware/firmware gives us. I suppose on all the existing platforms we
can just fix the firmware, I'm certainly not arguing that someone
shouldn't also send a patch for the firmware on this platform to the
appropriate place.
> For instance, on the Arndale the property "clock-frequency" exists but
> CNTFRQ is also correctly set.
That's harmless, if a bit stupid.
> > While grepping about this I noticed that make_timer_node doesn't use
> > DT_MATCH_TIMER, which I guess is just an accidental oversight, perhaps
> > if someone is fixing the clock-frequency issue they could throw in a
> > second patch for this too?
>
> I think it's an error during the cleanup.
>
> Regards,
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-18 13:37 ` Ian Campbell
@ 2014-03-18 15:41 ` Suriyan Ramasami
2014-03-18 16:09 ` Julien Grall
0 siblings, 1 reply; 19+ messages in thread
From: Suriyan Ramasami @ 2014-03-18 15:41 UTC (permalink / raw)
To: Ian Campbell; +Cc: Julien Grall, xen-devel
On Tue, Mar 18, 2014 at 6:37 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-03-18 at 12:04 +0000, Julien Grall wrote:
>> Hi Ian,
>>
>> On 03/18/2014 09:52 AM, Ian Campbell wrote:
>> > On Mon, 2014-03-17 at 22:15 +0000, Julien Grall wrote:
>> >>> 2. arch_timer_rate coming up as 0 in dom0 inspite of the dtb defining
>> >>> clock-frequency.
>> >>
>> >> The clock-frequency properties is not given to dom0. It should be able
>> >> to retrieve the frequency from the timer (CNTFRQ). That would mean that
>> >> u-boot is not correctly set up the frequency (it's the only one able to
>> >> do it as it need to be done in secure world).
>> >
>> > If the clock-frequency property is present in the host DT then that
>> > would imply that secure world is not setting CNTFRQ or is setting it
>> > wrong (since the property is effectively a workaround for that exact
>> > bug). Perhaps we should propagate it if it is present?
>>
>> It's easy to do it for dom0, what about guests? I think it would be
>> better to let the bootloader to set up the frequency. I'm a bit
>> surprised that it's not already the case for this board.
>
> Well, that's the issue -- sometimes we just need to deal with what the
> hardware/firmware gives us. I suppose on all the existing platforms we
> can just fix the firmware, I'm certainly not arguing that someone
> shouldn't also send a patch for the firmware on this platform to the
> appropriate place.
>
I am also trying to fix it in the boot loader. Nonetheless, I have a
gap in my understanding as to why using clock-frequency in domU would
create a problem?
If its OK for dom0 and domU to use clock-frequency in the case that
CNTFRQ comes up as 0, I would definitely submit a patch.
>> For instance, on the Arndale the property "clock-frequency" exists but
>> CNTFRQ is also correctly set.
>
> That's harmless, if a bit stupid.
>
>> > While grepping about this I noticed that make_timer_node doesn't use
>> > DT_MATCH_TIMER, which I guess is just an accidental oversight, perhaps
>> > if someone is fixing the clock-frequency issue they could throw in a
>> > second patch for this too?
>>
>> I think it's an error during the cleanup.
>>
>> Regards,
>>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ARM: EXYNOS 5410 - DOM0 not being scheduled
2014-03-18 15:41 ` Suriyan Ramasami
@ 2014-03-18 16:09 ` Julien Grall
0 siblings, 0 replies; 19+ messages in thread
From: Julien Grall @ 2014-03-18 16:09 UTC (permalink / raw)
To: Suriyan Ramasami; +Cc: Ian Campbell, xen-devel
Hi Suriyan,
On 03/18/2014 03:41 PM, Suriyan Ramasami wrote:
> I am also trying to fix it in the boot loader. Nonetheless, I have a
> gap in my understanding as to why using clock-frequency in domU would
> create a problem?
> If its OK for dom0 and domU to use clock-frequency in the case that
> CNTFRQ comes up as 0, I would definitely submit a patch.
The problem is not using "clock-frequency" into the guest, is how to
retrieve the clock frequency in libxl to correctly create the property?
One solution might be browsing /proc/devicetree, but it doesn't always
exists (e.g CONFIG_PROC_DEVICETREE=n).
Regards
--
Julien Grall
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-03-18 16:09 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-15 14:44 ARM: EXYNOS 5410 - DOM0 not being scheduled Suriyan Ramasami
2014-03-16 20:31 ` Julien Grall
2014-03-17 13:17 ` Suriyan Ramasami
2014-03-17 13:21 ` Julien Grall
2014-03-17 13:32 ` Suriyan Ramasami
2014-03-17 13:52 ` Julien Grall
2014-03-17 17:39 ` Suriyan Ramasami
2014-03-17 18:10 ` Suriyan Ramasami
2014-03-17 18:22 ` Suriyan Ramasami
2014-03-17 22:15 ` Julien Grall
2014-03-18 9:52 ` Ian Campbell
2014-03-18 12:04 ` Julien Grall
2014-03-18 13:37 ` Ian Campbell
2014-03-18 15:41 ` Suriyan Ramasami
2014-03-18 16:09 ` Julien Grall
2014-03-17 22:03 ` Julien Grall
2014-03-17 10:09 ` Ian Campbell
2014-03-17 13:24 ` Suriyan Ramasami
2014-03-17 13:36 ` Ian Campbell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.