Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-14 Thread Dushyant Behl 
On Sun, May 15, 2016 at 12:13 AM, Meng Xu  wrote:
> But I have a quick  question:
> With the following kernel booting log, did your dom0 boot up successfully?
> I mean, can you log into your dom0 now?

No, I was not able to boot the dom0 kernel successfully hence I was
not able to login into the dom0 linux.

Thanks,
Dushyant

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-14 Thread Dushyant Behl 
On Sun, May 15, 2016 at 12:07 AM, Meng Xu  wrote:
>>> some facilities to blacklist a device tree node (see blacklist dev in
>>> arm/platforms/tegra.c).
>>
>> I have blacklisted the tegra20_timer
>
> I guess you blocked the "tegra20-timer" (which uses "-" instead of
> "_") right as shown in the following patch? Am I right?

That was a typo in the email but I had blocked the correct timer, without
blacklisting the tegra timer the linux only boots to a few steps and
fails, in my next
bootlog linux booted a lot further and then failed due to some other reason.

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-14 Thread Meng Xu 
On Thu, Apr 14, 2016 at 11:54 AM, Dushyant Behl
 wrote:
> Hi Everyone,
>
> On Fri, Apr 8, 2016 at 5:57 PM, Ian Campbell  wrote:
>>> > In your patch for *Hacky* support for Jetsok-TK1 you said that you
>>> > were able to run guests on
>>> > Jetson-tk1 board with Xen. Can I know which kernel version you used as
>>> > dom0 (and possibly domU guests)?
>>
>> I'm afraid I don't remember. It would probably either have been some
>> current-ish upstream kernel from the time, or possibly a Debian kernel
>> from around the time. So maybe something 3.16-ish?
>
> @Ian Thanks for the Reply.
>
> @Julien, Thanks a lot, your patch for GIC dtb node worked and the
> linux kernel is now able to enable the arch timer.
> (Although I needed to modify the code manually as the tree I'm using
> is older Xen-4.6, and maybe the patch was against the latest version
> of xen).
>
> The kernel is able to initialize itself but it fails while initializing some
> nvidia devices in the boot process. I've posted the log here,

Thanks to Dyshyant's help, I see the similar log as Dushyant attached
in his email.

> Could this also be an issue with the device tree or this is something
> related to the kernel?

I plan to try the L4T kernel and see if the problem still exist.

But I have a quick  question:
With the following kernel booting log, did your dom0 boot up successfully?
I mean, can you log into your dom0 now?

>
> - UART enabled -
> - CPU  booting -
> - Xen starting in Hyp mode -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 8000 - ffef
> (XEN)
> (XEN) MODULE[0]: 8200 - 8201 Device Tree
> (XEN) MODULE[1]: 8100 - 815443f0 Kernel
> console=hvc0 root=/dev/mmcblk0p1 rw rootwait
> (XEN)  RESVD[0]: 8200 - 8201
> (XEN)
> (XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=512M
> sync_console log_lvl=all guest_loglvl=all
> (XEN) Placing Xen at 0xffc0-0xffe0
> (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
> ffc0-ffcf9701
> (XEN) Xen heap: fa00-fe00 (16384 pages)
> (XEN) Dom heap: 507648 pages
> (XEN) Domain heap initialised
> (XEN) Platform: TEGRA124
> (XEN) Looking for dtuart at "s Xen 4.6-unstable
> (XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc
> (Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Mon Apr 11 09:20:25 UTC
> 2016
> (XEN) Latest ChangeSet:
> (XEN) Console output is synchronous.
> (XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 1131:00011011
> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN)   Debug Features: 02010555
> (XEN)   Auxiliary Features: 
> (XEN)   Memory Model Features: 10201105 4000 0124 02102211
> (XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
> (XEN) Using PSCI-0.1 for SMP bringup
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz
> (XEN) GICv2 initialization:
> (XEN) gic_dist_addr=50041000
> (XEN) gic_cpu_addr=50042000
> (XEN) gic_hyp_addr=50044000
> (XEN) gic_vcpu_addr=50046000
> (XEN) gic_maintenance_irq=25
> (XEN) GICv2: 192 lines, 4 cpus, secure (IID 043b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) I/O virtualisation disabled
> (XEN) Allocated console ring of 32 KiB.
> (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> (XEN) Bringing up CPU1
> - CPU 0001 booting -
> - Xen starting in Hyp mode -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 1 booted.
> (XEN) Bringing up CPU2
> - CPU 0002 booting -
> - Xen starting in Hyp mode -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 2 booted.
> (XEN) Bringing up CPU3
> - CPU 0003 booting -
> - Xen starting in Hyp mode -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) CPU 3 booted.
> (XEN) Brought up 4 CPUs
> (XEN) P2M: 40-bit IPA
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 8100
> (XEN) zImage: no appended dtb
> (XEN) zImage32 Probe successful
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00a000-0x00c000 (512MB)
> (XEN) Additional MMIO 4-40040 (IRAM)
> (XEN) Additional MMIO 54200-54240 (Display A)
> (XEN) Additional MMIO 54240-54280 (Display B)
> (XEN) Additional MMIO 6000f-60010 (EXCEPTION VECTORS)
> (XEN) Additional MMIO 6000c-6000d (SYSREG)
> (XEN) Additional MMIO 1000-1001 (PCI CFG0)
> (XEN) Additional MMIO 1001-1002 (PCI CFG1)

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-14 Thread Meng Xu 
Hi Dushyant,

>>> On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall 
>>> wrote:

 On 14/03/16 14:19, Dushyant Behl wrote:
>>
>> Yes, I have enabled these configuration parameters when compiling linux
>> -


 The list of options looks good to me. I guess Linux is crashing before
 setting
 up the console. Can you apply the below to Linux and post the log here?
>>>
>>>
>>> I applied your patch to Linux but still there is no output from the
>>> kernel.
>>>
>>> But I have found location of the problem, I have a debugger attached
>>> to the Jetson board
>>> and using that I was able to find out that Linux is failing while
>>> initializing the Tegra timer.
>>>
>>> The call stack at the time of failing is  -
>>>
>>> -   prefetchw (inline)
>>>  arch_spin_lock (inline)
>>>  do_raw_spin_lock_flags (inline)
>>>  __raw_spin_lock_irqssave (inline)
>>>  raw_spin_lock_irq_save (lock = 0xC0B746F0)
>>> -   of_get_parent (node = 0xA1D3)
>>> -   of_get_address (dev = 0xDBBABC30, index = 0, size = 0xC0A83F30)
>>> -   of_address_to_resource(dev = 0xDBBABC30, index = 0, r = 0xC0A83F50)
>>> -   of_iomap (np = 0xDBBABC30, index = 0)
>>> -   tegra20_init_timer (np = 0xDBBABC30)
>>> -   clocksource_of_init()
>>> -   start_kernel()
>>>
>>> After this Linux jumps to floating point exception handler and then to
>>> undefined instruction and fails.
>>
>>
>> I don't know why Linux is receiving a floating point exception. However,
>> DOM0 must not use the tegra timer as it doesn't support virtualization.
>>
>> You need to ensure that DOM0 will use the arch timer instead. Xen provides
>> some facilities to blacklist a device tree node (see blacklist dev in
>> arm/platforms/tegra.c).
>
> I have blacklisted the tegra20_timer

I guess you blocked the "tegra20-timer" (which uses "-" instead of
"_") right as shown in the following patch? Am I right?

diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c

index 5ec9dda..8477ad1 100644

--- a/xen/arch/arm/platforms/tegra.c

+++ b/xen/arch/arm/platforms/tegra.c

@@ -431,6 +431,7 @@ static const struct dt_device_match
tegra_blacklist_dev[] __initconst =

  * UART to dom0, so don't map any of them.

  */

 DT_MATCH_COMPATIBLE("nvidia,tegra20-uart"),

+DT_MATCH_COMPATIBLE("nvidia,tegra20-timer"),

 { /* sentinel */ },

 };

Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-14 Thread Meng Xu 
Hi Dushyant,

On Sat, May 14, 2016 at 1:36 PM, Dushyant Behl
 wrote:
> Hey Meng,
>
> On Sat, May 14, 2016 at 7:39 AM, Meng Xu  wrote:
>>>
>>> http://dev.ktemkin.com/misc/xenarm-gic-parents.patch
>>
>> It seems this link is invalid now...
>> Has this patch been upstreamed?
>>
>> Hi Dushyant,
>> Could you help repost this patch in this email if it's not that large?
>> (Since we used the same repo, which is IanC's, it may be even better
>> if you could kindly share the patch based on the tegra-tk1-jetson-v1
>> branch of Ian's repo.?)
>
> The patch is attached with the mail.
>

Thank you so much for your help! I applied the patch and the kernel
can have further progress in booting.

I'm replying to your last email about the issue I'm facing to, which
seems not same with what you saw.

Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-14 Thread Dushyant Behl 
Hey Meng,

On Sat, May 14, 2016 at 7:39 AM, Meng Xu  wrote:
>>
>> http://dev.ktemkin.com/misc/xenarm-gic-parents.patch
>
> It seems this link is invalid now...
> Has this patch been upstreamed?
>
> Hi Dushyant,
> Could you help repost this patch in this email if it's not that large?
> (Since we used the same repo, which is IanC's, it may be even better
> if you could kindly share the patch based on the tegra-tk1-jetson-v1
> branch of Ian's repo.?)

The patch is attached with the mail.

Thanks,
Dushyant


xenarm-gic-parents.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-13 Thread Meng Xu 
Hi Julien and Dushyant,

>>>
 (XEN) DOM0: [0.00] irq: no irq domain found for
 /interrupt-controller !
 (XEN) DOM0: [0.00] irq: no irq domain found for
 /interrupt-controller !
 (XEN) DOM0: [0.00] irq: no irq domain found for
 /interrupt-controller !
 (XEN) DOM0: [0.00] arch_timer: No interrupt available, giving up
>>>
>>>
>>>
>>> It looks like to me that Xen is not recreating the device-tree correctly.
>>> I
>>> would look into the kernel to find what is expected.
>>
>>
>> This looks like a possible bug (or some missing feature) in Xen's
>> device tree creation which could
>> take some time to handle, so if I could be of any more help to you
>> with this issue please let me know.
>
>
> There was a conversation on #xen-arm few days ago about this problem.

Is there a way that we can see the conversation on #xen-arm?
I hope to better understand the problem.

> Xen doesn't correctly recreate the GIC node which result in a loop between
> the interrupt controller. Can you try the below patch?
>
> http://dev.ktemkin.com/misc/xenarm-gic-parents.patch

It seems this link is invalid now...
Has this patch been upstreamed?

Hi Dushyant,
Could you help repost this patch in this email if it's not that large?
(Since we used the same repo, which is IanC's, it may be even better
if you could kindly share the patch based on the tegra-tk1-jetson-v1
branch of Ian's repo.?)


Hi Julien,
Do you have some suggestions on how we can debug and fix the issue
related to the device tree?

I saw that there may still be some issues with the NVIDIA devices as
Dushyant described after he applied the patch.
Right now, I have the exact same board as Dushyant has. I think I may
encounter the exact same issue as he did. So I'm wondering if there is
some documentation/tutorial/notes that we can learn about how to debug
the issues.

Thank you both very much for your help and time!

Best Regards,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-12 Thread Dushyant Behl 
Hi Meng,

On Thu, May 12, 2016 at 6:30 AM, Meng Xu  wrote:
> Hi Dushyant,
>
> On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl  
> wrote:
>
> May I know which u-boot repo and which branch you used to enable the
> non-secure mode? If you could also share your u-boot config file, that
> will be awesome!

I'm using the u-boot from mainline git://git.denx.de/u-boot.git on my
Jetson board, I'm using the tegra-uboot-flasher-scripts from Nvidia
(https://github.com/NVIDIA/tegra-uboot-flasher-scripts)
to flash u-boot and they use the denx mainline branch with default
Jetson-TK1 configuration.

> The u-boot from NVIDEA didn't turn on the HYP mode. I tried the
> git://git.denx.de/u-boot.git, tag v2016.03, but the board won't boot
> after I flashed the uboot. No message at all... :-(
> If I use NVIDEA's uboot, I can boot into the linux kernel without problem.

The default configuration of u-boot doesn't enables HYP mode when you boot
the kernel. You can change that in the configuration by disabling

CONFIG_ARMV7_BOOT_SEC_DEFAULT in the config file.

But you can also achieve the same thing by setting the environment
variable in u-boot

"bootm_boot_mode=nonsec"

now booting the linux kernel through bootm command will boot it in HYP mode.
I'm also using the bootm_boot_mode variable set to nonsec without
changing the default
configuration of u-boot.

I had some problems booting the L4T kernel in HYP mode on Jetson, so I was using
the linux kernel from Jan Kiszka's development tree -
http://git.kiszka.org/linux.git/,  branch queues/assorted
which has some of the PSCI patches required to boot linux. Although If
you do get the
mainline linux or l4t kernel to boot in nonsec mode or on Xen, please
do let me know.

Thanks,
Dushyant

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-11 Thread Meng Xu 
Hi Dushyant,

On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl  wrote:
>
> Hi All,
>
> I'm working on a research project with IBM, and I want to run Xen on Nvidia 
> Tegra Jetson-tk1 board.
> I looked at a post on this mailing list 
> (http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01122.html),
> and I am using this git tree -
>
> git://xenbits.xen.org/people/ianc/xen.git
> and branch  - tegra-tk1-jetson-v1
>
> But when I try to boot Xen on the board I am not able to see any output (even 
> with earlyprintk enabled).
> After jumping to Xen the board just resets without showing any output.
>
> I am using upstream u-boot with non secure mode enabled.


I just got the Jetson TK1 board and I'm trying to run Xen on it.

May I know which u-boot repo and which branch you used to enable the
non-secure mode? If you could also share your u-boot config file, that
will be awesome!

The u-boot from NVIDEA didn't turn on the HYP mode. I tried the
git://git.denx.de/u-boot.git, tag v2016.03, but the board won't boot
after I flashed the uboot. No message at all... :-(
If I use NVIDEA's uboot, I can boot into the linux kernel without problem.

Thank you very much for your help and time!

Best Regards,

Meng

-- 
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-04-14 Thread Dushyant Behl 
Hi Everyone,

On Fri, Apr 8, 2016 at 5:57 PM, Ian Campbell  wrote:
>> > In your patch for *Hacky* support for Jetsok-TK1 you said that you
>> > were able to run guests on
>> > Jetson-tk1 board with Xen. Can I know which kernel version you used as
>> > dom0 (and possibly domU guests)?
>
> I'm afraid I don't remember. It would probably either have been some
> current-ish upstream kernel from the time, or possibly a Debian kernel
> from around the time. So maybe something 3.16-ish?

@Ian Thanks for the Reply.

@Julien, Thanks a lot, your patch for GIC dtb node worked and the
linux kernel is now able to enable the arch timer.
(Although I needed to modify the code manually as the tree I'm using
is older Xen-4.6, and maybe the patch was against the latest version
of xen).

The kernel is able to initialize itself but it fails while initializing some
nvidia devices in the boot process. I've posted the log here,
Could this also be an issue with the device tree or this is something
related to the kernel?

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 - ffef
(XEN)
(XEN) MODULE[0]: 8200 - 8201 Device Tree
(XEN) MODULE[1]: 8100 - 815443f0 Kernel
console=hvc0 root=/dev/mmcblk0p1 rw rootwait
(XEN)  RESVD[0]: 8200 - 8201
(XEN)
(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=512M
sync_console log_lvl=all guest_loglvl=all
(XEN) Placing Xen at 0xffc0-0xffe0
(XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
ffc0-ffcf9701
(XEN) Xen heap: fa00-fe00 (16384 pages)
(XEN) Dom heap: 507648 pages
(XEN) Domain heap initialised
(XEN) Platform: TEGRA124
(XEN) Looking for dtuart at "s Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc
(Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Mon Apr 11 09:20:25 UTC
2016
(XEN) Latest ChangeSet:
(XEN) Console output is synchronous.
(XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=50041000
(XEN) gic_cpu_addr=50042000
(XEN) gic_hyp_addr=50044000
(XEN) gic_vcpu_addr=50046000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 192 lines, 4 cpus, secure (IID 043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 32 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 8100
(XEN) zImage: no appended dtb
(XEN) zImage32 Probe successful
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x00a000-0x00c000 (512MB)
(XEN) Additional MMIO 4-40040 (IRAM)
(XEN) Additional MMIO 54200-54240 (Display A)
(XEN) Additional MMIO 54240-54280 (Display B)
(XEN) Additional MMIO 6000f-60010 (EXCEPTION VECTORS)
(XEN) Additional MMIO 6000c-6000d (SYSREG)
(XEN) Additional MMIO 1000-1001 (PCI CFG0)
(XEN) Additional MMIO 1001-1002 (PCI CFG1)
(XEN) Additional MMIO 12000-12010 (PCI IO)
(XEN) Additional MMIO 13000-2 (PCI MEM)
(XEN) Additional MMIO 2-4 (PCI MEM (PREFETCH))
(XEN) Additional IRQ 105 (DISPLAY)
(XEN) TEGRA: Routing IRQ105 to dom0, ICTLR2, mask 0x000200
(XEN) Additional IRQ 106 (DISPLAY B)
(XEN) TEGRA: Routing IRQ106 to dom0, ICTLR2, mask 0x000400
(XEN) Loading zImage from 8100 to a7a0-a7f443f0
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0xa800-0xa800f1d0
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) done.
(XEN)

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-04-08 Thread Ian Campbell 
On Fri, 2016-04-08 at 11:10 +0100, Julien Grall wrote:

> > In your patch for *Hacky* support for Jetsok-TK1 you said that you
> > were able to run guests on
> > Jetson-tk1 board with Xen. Can I know which kernel version you used as
> > dom0 (and possibly domU guests)?

I'm afraid I don't remember. It would probably either have been some
current-ish upstream kernel from the time, or possibly a Debian kernel
from around the time. So maybe something 3.16-ish?

Ian.

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-04-08 Thread Julien Grall 



On 07/04/16 08:48, Dushyant Behl wrote:

Hello,


Hi Dushyant,


On Fri, Apr 1, 2016 at 3:34 PM, Julien Grall  wrote:

Hello Dushyant,

On 29/03/16 21:56, Dushyant Behl wrote:


On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall 
wrote:


On 24/03/16 11:05, Dushyant Behl wrote:




(XEN) DOM0: [0.00] irq: no irq domain found for
/interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for
/interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for
/interrupt-controller !
(XEN) DOM0: [0.00] arch_timer: No interrupt available, giving up



It looks like to me that Xen is not recreating the device-tree correctly. I
would look into the kernel to find what is expected.


This looks like a possible bug (or some missing feature) in Xen's
device tree creation which could
take some time to handle, so if I could be of any more help to you
with this issue please let me know.


There was a conversation on #xen-arm few days ago about this problem.
Xen doesn't correctly recreate the GIC node which result in a loop 
between the interrupt controller. Can you try the below patch?


http://dev.ktemkin.com/misc/xenarm-gic-parents.patch



[I've cc'ed Ian Campbell in this mail (Sorry for cc'ing you explicitly)]


Ian's citrix e-mail is not valid anymore. I have CC'ed the new one.


Ian,

Actually, I want to run Xen on the Tegra Jetson board for some project
of mine but currently Linux-4.1 is
failing as dom0 because its not able to receive interrupts from the arch_timer.
This link contains the dom0 failure boot log -
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03715.html

In your patch for *Hacky* support for Jetsok-TK1 you said that you
were able to run guests on
Jetson-tk1 board with Xen. Can I know which kernel version you used as
dom0 (and possibly domU guests)?


Regards,

--
Julien Grall

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-04-07 Thread Dushyant Behl 
Hello,

On Fri, Apr 1, 2016 at 3:34 PM, Julien Grall  wrote:
> Hello Dushyant,
>
> On 29/03/16 21:56, Dushyant Behl wrote:
>>
>> On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall 
>> wrote:
>>>
>>> On 24/03/16 11:05, Dushyant Behl wrote:
>
>
>> (XEN) DOM0: [0.00] irq: no irq domain found for
>> /interrupt-controller !
>> (XEN) DOM0: [0.00] irq: no irq domain found for
>> /interrupt-controller !
>> (XEN) DOM0: [0.00] irq: no irq domain found for
>> /interrupt-controller !
>> (XEN) DOM0: [0.00] arch_timer: No interrupt available, giving up
>
>
> It looks like to me that Xen is not recreating the device-tree correctly. I
> would look into the kernel to find what is expected.

This looks like a possible bug (or some missing feature) in Xen's
device tree creation which could
take some time to handle, so if I could be of any more help to you
with this issue please let me know.

[I've cc'ed Ian Campbell in this mail (Sorry for cc'ing you explicitly)]

Ian,

Actually, I want to run Xen on the Tegra Jetson board for some project
of mine but currently Linux-4.1 is
failing as dom0 because its not able to receive interrupts from the arch_timer.
This link contains the dom0 failure boot log -
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03715.html

In your patch for *Hacky* support for Jetsok-TK1 you said that you
were able to run guests on
Jetson-tk1 board with Xen. Can I know which kernel version you used as
dom0 (and possibly domU guests)?

Thanks and Regards,
Dushyant Behl

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-04-01 Thread Julien Grall 

Hello Dushyant,

On 29/03/16 21:56, Dushyant Behl wrote:

On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall  wrote:

On 24/03/16 11:05, Dushyant Behl wrote:



(XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !
(XEN) DOM0: [0.00] arch_timer: No interrupt available, giving up


It looks like to me that Xen is not recreating the device-tree 
correctly. I would look into the kernel to find what is expected.


Regards,

--
Julien Grall

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-29 Thread Dushyant Behl 
Hi Julian,

Thanks for the reply.

On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall  wrote:
> Hello Dushyant,
>
> On 24/03/16 11:05, Dushyant Behl wrote:
>>
>> I was not receiving the dom0 logs because of a mistake in my dom0
>> bootargs. In the bootargs the option
>> for earlyprintk was not marked as Xen. Now that I've enabled it I'm
>> able to see some bootlog from dom0 linux.
>>
>> At least now I'm able to figure out the reason of Linux running into
>> infinite loop.
>>
>> It seems like Linux is not receiving any interrupts from the arch
>> timer and when it tries
>> to calibrate the timer delay then there's a loop where linux waits to
>> receive ticks to calculate
>> loops_per_jiffies and that's the point where dom0 is running into the
>> infinite loop.
>> (exact point is http://osxr.org:8080/linux/source/init/calibrate.c#0196)
>>
>> This is the dom0 bootlog which I received after correcting the
>> earlyprintk argument -
>
>
> Can you provide the full log? So we can see if there is anything which could
> give us a hint about your problem.

This is the complete log of Xen + Dom0 -

## Booting kernel from Legacy Image at fd00 ...
   Image Name:   Xen unstable build
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:721776 Bytes = 704.9 KiB
   Load Address: fd00
   Entry Point:  fd00
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8200
   Booting using the fdt blob at 0x8200
   Loading Kernel Image ... OK
   reserving fdt memory region: addr=8200 size=1
   Using Device Tree in place at 8200, end 82012fff

Starting kernel ...

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 - ffef
(XEN)
(XEN) MODULE[0]: 8200 - 8201 Device Tree
(XEN) MODULE[1]: 8100 - 81544828 Kernel
console=hvc0 console=tty1 earlyprintk=xen root=/dev/mmcblk0p1 rw
rootwait tegraid=40.1.1.0.0
(XEN)  RESVD[0]: 8200 - 8201
(XEN)
(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=512M
(XEN) Placing Xen at 0xffc0-0xffe0
(XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
ffc0-ffcf9701
(XEN) Xen heap: fa00-fe00 (16384 pages)
(XEN) Dom heap: 507648 pages
(XEN) Domain heap initialised
(XEN) Platform: TEGRA124
(XEN) Looking for dtuart at "s Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc
(Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Thu Mar 24 08:02:39 UTC
2016
(XEN) Latest ChangeSet:
(XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=50041000
(XEN) gic_cpu_addr=50042000
(XEN) gic_hyp_addr=50044000
(XEN) gic_vcpu_addr=50046000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 192 lines, 4 cpus, secure (IID 043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 32 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 8100
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x00a000-0x00c000 (512MB)
(XEN) Additional MMIO 4-40040 (IRAM)
(XEN) Additional MMIO 54200-54240 (Display A)
(XEN) Additional MMIO 54240-54280 (Display B)
(XEN) Additional MMIO 6000f-60010 (EXCEPTION VECTORS)
(XEN) Additional MMIO 6000c-6000d (SYSREG)
(XEN) Additional MMIO 1000-1001 (PCI CFG0)
(XEN) Additional MMIO 1001-1002 (PCI CFG1)
(XEN) Additional MMIO 12000-12010 (PCI IO)
(XEN) Additional MMIO 13000-2 (PCI

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-29 Thread Julien Grall 

Hello Dushyant,

On 24/03/16 11:05, Dushyant Behl wrote:

I was not receiving the dom0 logs because of a mistake in my dom0
bootargs. In the bootargs the option
for earlyprintk was not marked as Xen. Now that I've enabled it I'm
able to see some bootlog from dom0 linux.

At least now I'm able to figure out the reason of Linux running into
infinite loop.

It seems like Linux is not receiving any interrupts from the arch
timer and when it tries
to calibrate the timer delay then there's a loop where linux waits to
receive ticks to calculate
loops_per_jiffies and that's the point where dom0 is running into the
infinite loop.
(exact point is http://osxr.org:8080/linux/source/init/calibrate.c#0196)

This is the dom0 bootlog which I received after correcting the
earlyprintk argument -


Can you provide the full log? So we can see if there is anything which 
could give us a hint about your problem.




(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
(XEN) DOM0: [0.00] Booting Linux on physical CPU 0x0
(XEN) DOM0: [0.00] Initializing cgroup subsys cpu
(XEN) DOM0: [0.00] Initializing cgroup subsys cpuacct
(XEN) DOM0: [0.00] Linux version
4.1.0-196898-g2e68ed9-dirty(root@ubuntu-server) (gcc version 4.7.3
(Ubuntu/Linaro 4.7.3-11ubuntu
(XEN) DOM0: 1) ) #12 SMP PREEMPT Thu Mar 24 09:56:36 UTC 2016
(XEN) DOM0: [0.00] CPU: ARMv7 Processor [413fc0f3] revision 3
(ARMv7), cr=30c5387d
(XEN) DOM0: [0.00] CPU: PIPT / VIPT nonaliasing data cache,
PIPT instruction cache
(XEN) DOM0: [0.00] Machine model: NVIDIA Tegra124 Jetson TK1
(XEN) DOM0: [0.00] bootconsole [earlycon0] enabled
(XEN) DOM0: [0.00] cma: Reserved 64 MiB at 0xbc00
(XEN) DOM0: [0.00] Forcing write-allocate cache policy for SMP
(XEN) DOM0: [0.00] Memory policy: Data cache writealloc
(XEN) DOM0: [0.00] psci: probing for conduit method from DT.
(XEN) DOM0: [0.00] psci: PSCIv0.2 detected in firmware.
(XEN) DOM0: [0.00] psci: Using standard PSCI v0.2 function IDs
(XEN) DOM0: [0.00] PERCPU: Embedded 12 pages/cpu @dbb77000
s19712 r8192 d21248 u49152
(XEN) DOM0: [0.00] Built 1 zonelists in Zone order, mobility
grouping on.  Total pages: 130048
(XEN) DOM0: [0.00] Kernel command line: console=hvc0
console=tty1 earlyprintk=xen root=/dev/mmcblk0p1 rw rootwait
tegraid=40.1.1.0.0
(XEN) DOM0: [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
(XEN) DOM0: [0.00] Dentry cache hash table entries: 65536
(order: 6, 262144 bytes)
(XEN) DOM0: [0.00] Inode-cache hash table entries: 32768
(order: 5, 131072 bytes)
(XEN) DOM0: [0.00] Memory: 441884K/524288K available (7657K
kernel code, 634K rwdata, 2584K rodata, 484K init, 383K bss, 16868K
reserved, 65536K cma-reserved, 0K highmem)
(XEN) DOM0: [0.00] Virtual kernel memory layout:
(XEN) DOM0: [0.00] vector  : 0x - 0x1000   (   4 kB)
(XEN) DOM0: [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
(XEN) DOM0: [0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
(XEN) DOM0: [0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
(XEN) DOM0: [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
(XEN) DOM0: [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
(XEN) DOM0: [0.00]   .text : 0xc0008000 - 0xc0a08c10   (10244 kB)
(XEN) DOM0: [0.00]   .init : 0xc0a09000 - 0xc0a82000   ( 484 kB)
(XEN) DOM0: [0.00]   .data : 0xc0a82000 - 0xc0b20bec   ( 635 kB)
(XEN) DOM0: [0.00].bss : 0xc0b23000 - 0xc0b82ea0   ( 384 kB)
(XEN) DOM0: [0.00] Preemptible hierarchical RCU implementation.
(XEN) DOM0: [0.00] Build-time adjustment of leaf fanout to 32.
(XEN) DOM0: [0.00] NR_IRQS:16 nr_irqs:16 16
(XEN) DOM0: [0.00] of_irq_init: children remain, but no parents
(XEN) DOM0: [0.00] L2C: failed to init: -19
(XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !
(XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !
(XEN) DOM0: [0.00] arch_timer: No interrupt available, giving up
(XEN) DOM0: [0.00] sched_clock: 32 bits at 100 Hz, resolution
1000ns, wraps every 2147483647500ns
(XEN) DOM0: [0.00] Console: colour dummy device 80x30
(XEN) DOM0: [0.00] console [tty1] enabled

Can anyone explain why Linux is not able to get any interrupts from
the arch timer?
Is this some problem with Xen's interrupt mappings or some issue with
the dom0 kernel?


From the log: "arch_timer: No interrupt available, giving up". So the 
kernel is not able to get the interrupt from device tree.

Which device-tree are you using for the board?

Regards,

--
Julien Grall

___
Xen-devel mailing list

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-24 Thread Dushyant Behl 
Hi Everyone,

On Mon, Mar 21, 2016 at 3:42 PM, Dushyant Behl
 wrote:
> Hi Julien,
>
> On Fri, Mar 18, 2016 at 10:53 PM, Julien Grall  wrote:
>>
>>
>> On 18/03/16 15:01, Dushyant Behl wrote:
>>>
>>> Hi Julien,
>>
>>
>> Hi Dushyant,
>>
>>> On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall 
>>> wrote:

 On 14/03/16 14:19, Dushyant Behl wrote:
>>
>> Yes, I have enabled these configuration parameters when compiling linux
>> -


 The list of options looks good to me. I guess Linux is crashing before
 setting
 up the console. Can you apply the below to Linux and post the log here?
>>>
>>>
>>> I applied your patch to Linux but still there is no output from the
>>> kernel.
>>>
>>> But I have found location of the problem, I have a debugger attached
>>> to the Jetson board
>>> and using that I was able to find out that Linux is failing while
>>> initializing the Tegra timer.
>>>
>>> The call stack at the time of failing is  -
>>>
>>> -   prefetchw (inline)
>>>  arch_spin_lock (inline)
>>>  do_raw_spin_lock_flags (inline)
>>>  __raw_spin_lock_irqssave (inline)
>>>  raw_spin_lock_irq_save (lock = 0xC0B746F0)
>>> -   of_get_parent (node = 0xA1D3)
>>> -   of_get_address (dev = 0xDBBABC30, index = 0, size = 0xC0A83F30)
>>> -   of_address_to_resource(dev = 0xDBBABC30, index = 0, r = 0xC0A83F50)
>>> -   of_iomap (np = 0xDBBABC30, index = 0)
>>> -   tegra20_init_timer (np = 0xDBBABC30)
>>> -   clocksource_of_init()
>>> -   start_kernel()
>>>
>>> After this Linux jumps to floating point exception handler and then to
>>> undefined instruction and fails.
>>
>>
>> I don't know why Linux is receiving a floating point exception. However,
>> DOM0 must not use the tegra timer as it doesn't support virtualization.
>>
>> You need to ensure that DOM0 will use the arch timer instead. Xen provides
>> some facilities to blacklist a device tree node (see blacklist dev in
>> arm/platforms/tegra.c).
>
> I have blacklisted the tegra20_timer and now dom0 is able to pass that
> step but now the dom0 kernel gets stuck in an infinite loop in the
> function calibrate_delay_converge.
>
> This is the call stack -
>  -  calibrate_delay_converge
>  -  calibrate_delay
>  -  start_kernel
>
> Right now I'm not sure about the exact point where it is going into
> the infinite loop.

I was not receiving the dom0 logs because of a mistake in my dom0
bootargs. In the bootargs the option
for earlyprintk was not marked as Xen. Now that I've enabled it I'm
able to see some bootlog from dom0 linux.

At least now I'm able to figure out the reason of Linux running into
infinite loop.

It seems like Linux is not receiving any interrupts from the arch
timer and when it tries
to calibrate the timer delay then there's a loop where linux waits to
receive ticks to calculate
loops_per_jiffies and that's the point where dom0 is running into the
infinite loop.
(exact point is http://osxr.org:8080/linux/source/init/calibrate.c#0196)

This is the dom0 bootlog which I received after correcting the
earlyprintk argument -

(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
(XEN) DOM0: [0.00] Booting Linux on physical CPU 0x0
(XEN) DOM0: [0.00] Initializing cgroup subsys cpu
(XEN) DOM0: [0.00] Initializing cgroup subsys cpuacct
(XEN) DOM0: [0.00] Linux version
4.1.0-196898-g2e68ed9-dirty(root@ubuntu-server) (gcc version 4.7.3
(Ubuntu/Linaro 4.7.3-11ubuntu
(XEN) DOM0: 1) ) #12 SMP PREEMPT Thu Mar 24 09:56:36 UTC 2016
(XEN) DOM0: [0.00] CPU: ARMv7 Processor [413fc0f3] revision 3
(ARMv7), cr=30c5387d
(XEN) DOM0: [0.00] CPU: PIPT / VIPT nonaliasing data cache,
PIPT instruction cache
(XEN) DOM0: [0.00] Machine model: NVIDIA Tegra124 Jetson TK1
(XEN) DOM0: [0.00] bootconsole [earlycon0] enabled
(XEN) DOM0: [0.00] cma: Reserved 64 MiB at 0xbc00
(XEN) DOM0: [0.00] Forcing write-allocate cache policy for SMP
(XEN) DOM0: [0.00] Memory policy: Data cache writealloc
(XEN) DOM0: [0.00] psci: probing for conduit method from DT.
(XEN) DOM0: [0.00] psci: PSCIv0.2 detected in firmware.
(XEN) DOM0: [0.00] psci: Using standard PSCI v0.2 function IDs
(XEN) DOM0: [0.00] PERCPU: Embedded 12 pages/cpu @dbb77000
s19712 r8192 d21248 u49152
(XEN) DOM0: [0.00] Built 1 zonelists in Zone order, mobility
grouping on.  Total pages: 130048
(XEN) DOM0: [0.00] Kernel command line: console=hvc0
console=tty1 earlyprintk=xen root=/dev/mmcblk0p1 rw rootwait
tegraid=40.1.1.0.0
(XEN) DOM0: [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
(XEN) DOM0: [0.00] Dentry cache hash table entries: 65536
(order: 6, 262144 bytes)
(XEN) DOM0: [0.00] Inode-cache hash table entries: 32768
(order: 5, 131072 bytes)
(XEN) DOM0: [0.00] Memory: 441884K/524288K available (7657K
kernel code, 634K rwdata, 2584K

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-21 Thread Dushyant Behl 
Hi Julien,

On Fri, Mar 18, 2016 at 10:53 PM, Julien Grall  wrote:
>
>
> On 18/03/16 15:01, Dushyant Behl wrote:
>>
>> Hi Julien,
>
>
> Hi Dushyant,
>
>> On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall 
>> wrote:
>>>
>>> On 14/03/16 14:19, Dushyant Behl wrote:
>
> Yes, I have enabled these configuration parameters when compiling linux
> -
>>>
>>>
>>> The list of options looks good to me. I guess Linux is crashing before
>>> setting
>>> up the console. Can you apply the below to Linux and post the log here?
>>
>>
>> I applied your patch to Linux but still there is no output from the
>> kernel.
>>
>> But I have found location of the problem, I have a debugger attached
>> to the Jetson board
>> and using that I was able to find out that Linux is failing while
>> initializing the Tegra timer.
>>
>> The call stack at the time of failing is  -
>>
>> -   prefetchw (inline)
>>  arch_spin_lock (inline)
>>  do_raw_spin_lock_flags (inline)
>>  __raw_spin_lock_irqssave (inline)
>>  raw_spin_lock_irq_save (lock = 0xC0B746F0)
>> -   of_get_parent (node = 0xA1D3)
>> -   of_get_address (dev = 0xDBBABC30, index = 0, size = 0xC0A83F30)
>> -   of_address_to_resource(dev = 0xDBBABC30, index = 0, r = 0xC0A83F50)
>> -   of_iomap (np = 0xDBBABC30, index = 0)
>> -   tegra20_init_timer (np = 0xDBBABC30)
>> -   clocksource_of_init()
>> -   start_kernel()
>>
>> After this Linux jumps to floating point exception handler and then to
>> undefined instruction and fails.
>
>
> I don't know why Linux is receiving a floating point exception. However,
> DOM0 must not use the tegra timer as it doesn't support virtualization.
>
> You need to ensure that DOM0 will use the arch timer instead. Xen provides
> some facilities to blacklist a device tree node (see blacklist dev in
> arm/platforms/tegra.c).

I have blacklisted the tegra20_timer and now dom0 is able to pass that
step but now the dom0 kernel gets stuck in an infinite loop in the
function calibrate_delay_converge.

This is the call stack -
 -  calibrate_delay_converge
 -  calibrate_delay
 -  start_kernel

Right now I'm not sure about the exact point where it is going into
the infinite loop.

Thanks,
Dushyant Behl

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-19 Thread Julien Grall 



On 18/03/16 15:01, Dushyant Behl wrote:

Hi Julien,


Hi Dushyant,


On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall  wrote:

On 14/03/16 14:19, Dushyant Behl wrote:

Yes, I have enabled these configuration parameters when compiling linux -


The list of options looks good to me. I guess Linux is crashing before setting
up the console. Can you apply the below to Linux and post the log here?


I applied your patch to Linux but still there is no output from the kernel.

But I have found location of the problem, I have a debugger attached
to the Jetson board
and using that I was able to find out that Linux is failing while
initializing the Tegra timer.

The call stack at the time of failing is  -

-   prefetchw (inline)
 arch_spin_lock (inline)
 do_raw_spin_lock_flags (inline)
 __raw_spin_lock_irqssave (inline)
 raw_spin_lock_irq_save (lock = 0xC0B746F0)
-   of_get_parent (node = 0xA1D3)
-   of_get_address (dev = 0xDBBABC30, index = 0, size = 0xC0A83F30)
-   of_address_to_resource(dev = 0xDBBABC30, index = 0, r = 0xC0A83F50)
-   of_iomap (np = 0xDBBABC30, index = 0)
-   tegra20_init_timer (np = 0xDBBABC30)
-   clocksource_of_init()
-   start_kernel()

After this Linux jumps to floating point exception handler and then to
undefined instruction and fails.


I don't know why Linux is receiving a floating point exception. However, 
DOM0 must not use the tegra timer as it doesn't support virtualization.


You need to ensure that DOM0 will use the arch timer instead. Xen 
provides some facilities to blacklist a device tree node (see blacklist 
dev in arm/platforms/tegra.c).


Regards,

--
Julien Grall

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-19 Thread Dushyant Behl 
Hi Julien,

On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall  wrote:
> Hi Dushyant,
>
> On 14/03/16 14:19, Dushyant Behl wrote:
>> > Yes, I have enabled these configuration parameters when compiling linux -
>
> The list of options looks good to me. I guess Linux is crashing before setting
> up the console. Can you apply the below to Linux and post the log here?

I applied your patch to Linux but still there is no output from the kernel.

But I have found location of the problem, I have a debugger attached
to the Jetson board
and using that I was able to find out that Linux is failing while
initializing the Tegra timer.

The call stack at the time of failing is  -

-   prefetchw (inline)
arch_spin_lock (inline)
do_raw_spin_lock_flags (inline)
__raw_spin_lock_irqssave (inline)
raw_spin_lock_irq_save (lock = 0xC0B746F0)
-   of_get_parent (node = 0xA1D3)
-   of_get_address (dev = 0xDBBABC30, index = 0, size = 0xC0A83F30)
-   of_address_to_resource(dev = 0xDBBABC30, index = 0, r = 0xC0A83F50)
-   of_iomap (np = 0xDBBABC30, index = 0)
-   tegra20_init_timer (np = 0xDBBABC30)
-   clocksource_of_init()
-   start_kernel()

After this Linux jumps to floating point exception handler and then to
undefined instruction and fails.

Thanks,
Dushyant

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-19 Thread Julien Grall 
Hi Dushyant,

On 14/03/16 14:19, Dushyant Behl wrote:
> > Yes, I have enabled these configuration parameters when compiling linux -

The list of options looks good to me. I guess Linux is crashing before setting
up the console. Can you apply the below to Linux and post the log here?

Regards,

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c963ba5..6f3b85b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1657,6 +1657,8 @@ static size_t cont_print_text(char *text, size_t size)
return textlen;
 }
 
+#include 
+
 asmlinkage int vprintk_emit(int facility, int level,
const char *dict, size_t dictlen,
const char *fmt, va_list args)
@@ -1724,6 +1726,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 * prefix which might be passed-in as a parameter.
 */
text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
+   xen_raw_console_write(text);
 
/* mark and strip a trailing newline */
if (text_len && text[text_len-1] == '\n') {

-- 
Julien Grall

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-14 Thread Dushyant Behl 
Hi Konrad,

On Mon, Mar 14, 2016 at 7:42 PM, Konrad Rzeszutek Wilk
 wrote:
>> After changing the console name to hvc0 the only thing which I noticed
>> differently is
>> that after the last line where Xen frees some init memory, I am able to see
>> the linux
>> kernel decompression message -
>>
>> "(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
>>
>> But after that the system just hangs the same way without any response on
>> the network either.
>
> Has Linux been compiled with the appropiate CONFIG_ parameters? That is you
> have Xen enabled on it?

Yes, I have enabled these configuration parameters when compiling linux -

CONFIG_XEN_DOM0=y
CONFIG_XEN=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=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=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_AUTO_XLATE=y

Thanks,
Dushyant

>>
>> Thanks,
>> Dushyant
>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-14 Thread Konrad Rzeszutek Wilk 
> After changing the console name to hvc0 the only thing which I noticed
> differently is
> that after the last line where Xen frees some init memory, I am able to see
> the linux
> kernel decompression message -
> 
> "(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
> 
> But after that the system just hangs the same way without any response on
> the network either.

Has Linux been compiled with the appropiate CONFIG_ parameters? That is you
have Xen enabled on it?

> 
> Thanks,
> Dushyant

> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-14 Thread Dushyant Behl 
Hi Meng,

On Sun, Mar 13, 2016 at 7:40 AM, Meng Xu  wrote:

> On Sat, Mar 12, 2016 at 3:23 PM, Dushyant Behl
>  wrote:
> > Hi Meng,
> >
> > On Sat, Mar 12, 2016 at 8:57 PM, Meng Xu  wrote:
> >>
> >> On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl
> >>  wrote:
> >> > Hi Julien,
> >> >
> >> > Thanks for the quick reply.
> >> >
> >> > On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall 
> >> > wrote:
> >> >>
> >> >> Hi Dushyant,
> >> >>
> >> >> On 09/03/2016 20:37, Wei Liu wrote:
> >> >>>
> >> >>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
> >> 
> >>  I'm working on a research project with IBM, and I want to run Xen
> on
> >>  Nvidia
> >>  Tegra Jetson-tk1 board.
> >>  I looked at a post on this mailing list
> >>  (http://lists.xenproject.org/archives/
> >>  html/xen-devel/2015-03/msg01122.html),
> >>  and I am using this git tree -
> >> 
> >>  git://xenbits.xen.org/people/ianc/xen.git
> >>  and branch  - tegra-tk1-jetson-v1
> >> 
> >>  But when I try to boot Xen on the board I am not able to see any
> >>  output
> >>  (even
> >>  with earlyprintk enabled).
> >>  After jumping to Xen the board just resets without showing any
> >>  output.
> >> 
> >>  I am using upstream u-boot with non secure mode enabled. I have
> also
> >>  tested
> >>  booting the Linux kernel on the same setup
> >>  and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm
> >>  enabled.
> >> 
> >>  Can anyone help me as to what I might have done wrong while using
> >>  Xen?
> >> >>
> >> >>
> >> >> I never tried to boot Xen on Jetson-TK1 myself.
> >> >>
> >> >> Could you provide the command line you use to compile Xen (with
> >> >> earlyprintk enabled) and the U-boot runes?
> >> >
> >> >
> >> > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro
> >> > arm-linux-gnueabihf-gcc 4.7.3
> >> > as the cross compiler to compile everything. The tree which I pointed
> >> > towards (in my previous mail)
> >> > contains the earlyprintk configurations for Jetson-TK1, so I am using
> >> > this
> >> > command to compile Xen with earlyprintk -
> >> >
> >> > make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32
> >> >
> >> > I want to update my current stage with Xen, after using this
> toolchain I
> >> > am
> >> > able to get Xen to print output
> >> > on the Jetson-TK1's serial console and Xen is able to boot correctly
> >> > with
> >> > all 4 cores in HYP mode.
> >> >
> >> > But the problem is when Xen tries to boot the dom0 kernel and transfer
> >> > control, I receive no output on the serial port.
> >> > I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled
> >> > with
> >> > Xen specific options enabled.
> >> > Also the same linux kernel is able to boot on the board without Xen.
> >> >
> >> > I am passing the dom0 kernel argument to Xen in the /chosen node in
> the
> >> > device tree using these commands  -
> >> >
> >> > fdt mknod /chosen module
> >> > fdt set /chosen/module compatible "xen,linux-zimage"
> >> > "xen,multiboot-module"
> >> > fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize>
> >> > fdt set /chosen/module bootargs "$bootargs"
> >>
> >> I haven't run Xen on ARM yet. But just a random thought:
> >> Is it possible that you need to provide the console=hvc0 for the boot
> >> cmdline of dom0?
> >>
> >> dom0 needs share the serial port with Xen.
> >
> >
> > I have added the serial port in the bootargs passed to the kernel. The
> > bootargs
> > passed to the dom0 when executing with Xen are the same bootargs which I
> > pass
> > when I run the kernel standalone without Xen and at that time I am able
> to
> > see the
> > kernel bootlog and a tty console on the serial port.
>
> Ahha, that's the problem!
>
> when Linux runs in native env., it will use serial port, say com1, you
> can use console=com1 or console ttyS0 for the boot cmd.
> However, when you run linux in dom0, linux won't see the hardware
> ttyS0 directly. It must go through Xen to see it. So the linux's
> cmdline in dom0 must be console=hvc0, instead of ttyS0 or com1.
>
> Can you try this and see if it fix the problem?


Thanks for pointing this out, I changed the console name when booting linux
as dom0.

>
> >>
> >> >
> >> > I am loading Xen at top of the ram and linux and device tree at their
> >> > default locations (near starting of ram).
> >> >
> >> > This is the Xen BootLog which I receive through the earlyprintk serial
> >> > port
> >> > -
> >> >
> >> > - UART enabled -
> >> > - CPU  booting -
> >> > - Xen starting in Hyp mode -
> >> > - Zero BSS -
> >> > - Setting up control registers -
> >> > - CPU Init Done -- Turning on paging -
> >> > - Ready -
> >> > (XEN) Checking for initrd in /chosen
> >> > (XEN) RAM: 8000 - ffef
>

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-12 Thread Meng Xu 
On Sat, Mar 12, 2016 at 3:23 PM, Dushyant Behl
 wrote:
> Hi Meng,
>
> On Sat, Mar 12, 2016 at 8:57 PM, Meng Xu  wrote:
>>
>> On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl
>>  wrote:
>> > Hi Julien,
>> >
>> > Thanks for the quick reply.
>> >
>> > On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall 
>> > wrote:
>> >>
>> >> Hi Dushyant,
>> >>
>> >> On 09/03/2016 20:37, Wei Liu wrote:
>> >>>
>> >>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
>> 
>>  I'm working on a research project with IBM, and I want to run Xen on
>>  Nvidia
>>  Tegra Jetson-tk1 board.
>>  I looked at a post on this mailing list
>>  (http://lists.xenproject.org/archives/
>>  html/xen-devel/2015-03/msg01122.html),
>>  and I am using this git tree -
>> 
>>  git://xenbits.xen.org/people/ianc/xen.git
>>  and branch  - tegra-tk1-jetson-v1
>> 
>>  But when I try to boot Xen on the board I am not able to see any
>>  output
>>  (even
>>  with earlyprintk enabled).
>>  After jumping to Xen the board just resets without showing any
>>  output.
>> 
>>  I am using upstream u-boot with non secure mode enabled. I have also
>>  tested
>>  booting the Linux kernel on the same setup
>>  and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm
>>  enabled.
>> 
>>  Can anyone help me as to what I might have done wrong while using
>>  Xen?
>> >>
>> >>
>> >> I never tried to boot Xen on Jetson-TK1 myself.
>> >>
>> >> Could you provide the command line you use to compile Xen (with
>> >> earlyprintk enabled) and the U-boot runes?
>> >
>> >
>> > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro
>> > arm-linux-gnueabihf-gcc 4.7.3
>> > as the cross compiler to compile everything. The tree which I pointed
>> > towards (in my previous mail)
>> > contains the earlyprintk configurations for Jetson-TK1, so I am using
>> > this
>> > command to compile Xen with earlyprintk -
>> >
>> > make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32
>> >
>> > I want to update my current stage with Xen, after using this toolchain I
>> > am
>> > able to get Xen to print output
>> > on the Jetson-TK1's serial console and Xen is able to boot correctly
>> > with
>> > all 4 cores in HYP mode.
>> >
>> > But the problem is when Xen tries to boot the dom0 kernel and transfer
>> > control, I receive no output on the serial port.
>> > I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled
>> > with
>> > Xen specific options enabled.
>> > Also the same linux kernel is able to boot on the board without Xen.
>> >
>> > I am passing the dom0 kernel argument to Xen in the /chosen node in the
>> > device tree using these commands  -
>> >
>> > fdt mknod /chosen module
>> > fdt set /chosen/module compatible "xen,linux-zimage"
>> > "xen,multiboot-module"
>> > fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize>
>> > fdt set /chosen/module bootargs "$bootargs"
>>
>> I haven't run Xen on ARM yet. But just a random thought:
>> Is it possible that you need to provide the console=hvc0 for the boot
>> cmdline of dom0?
>>
>> dom0 needs share the serial port with Xen.
>
>
> I have added the serial port in the bootargs passed to the kernel. The
> bootargs
> passed to the dom0 when executing with Xen are the same bootargs which I
> pass
> when I run the kernel standalone without Xen and at that time I am able to
> see the
> kernel bootlog and a tty console on the serial port.

Ahha, that's the problem!

when Linux runs in native env., it will use serial port, say com1, you
can use console=com1 or console ttyS0 for the boot cmd.
However, when you run linux in dom0, linux won't see the hardware
ttyS0 directly. It must go through Xen to see it. So the linux's
cmdline in dom0 must be console=hvc0, instead of ttyS0 or com1.

Can you try this and see if it fix the problem?

>
>>
>> >
>> > I am loading Xen at top of the ram and linux and device tree at their
>> > default locations (near starting of ram).
>> >
>> > This is the Xen BootLog which I receive through the earlyprintk serial
>> > port
>> > -
>> >
>> > - UART enabled -
>> > - CPU  booting -
>> > - Xen starting in Hyp mode -
>> > - Zero BSS -
>> > - Setting up control registers -
>> > - CPU Init Done -- Turning on paging -
>> > - Ready -
>> > (XEN) Checking for initrd in /chosen
>> > (XEN) RAM: 8000 - ffef
>> > (XEN)
>> > (XEN) MODULE[0]: 8200 - 8201 Device Tree
>> > (XEN) MODULE[1]: 8100 - 8158 Kernel
>> > (XEN)  RESVD[0]: 8200 - 8201
>> > (XEN)
>> > (XEN) Command line: 
>> > (XEN) Placing Xen at 0xffc0-0xffe0
>> > (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
>> > ffc0-ffcf9701
>> > (XEN) Xen heap:

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-12 Thread Dushyant Behl 
Hi Meng,

On Sat, Mar 12, 2016 at 8:57 PM, Meng Xu  wrote:

> On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl
>  wrote:
> > Hi Julien,
> >
> > Thanks for the quick reply.
> >
> > On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall 
> wrote:
> >>
> >> Hi Dushyant,
> >>
> >> On 09/03/2016 20:37, Wei Liu wrote:
> >>>
> >>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
> 
>  I'm working on a research project with IBM, and I want to run Xen on
>  Nvidia
>  Tegra Jetson-tk1 board.
>  I looked at a post on this mailing list
>  (http://lists.xenproject.org/archives/
>  html/xen-devel/2015-03/msg01122.html),
>  and I am using this git tree -
> 
>  git://xenbits.xen.org/people/ianc/xen.git
>  and branch  - tegra-tk1-jetson-v1
> 
>  But when I try to boot Xen on the board I am not able to see any
> output
>  (even
>  with earlyprintk enabled).
>  After jumping to Xen the board just resets without showing any output.
> 
>  I am using upstream u-boot with non secure mode enabled. I have also
>  tested
>  booting the Linux kernel on the same setup
>  and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm
>  enabled.
> 
>  Can anyone help me as to what I might have done wrong while using Xen?
> >>
> >>
> >> I never tried to boot Xen on Jetson-TK1 myself.
> >>
> >> Could you provide the command line you use to compile Xen (with
> >> earlyprintk enabled) and the U-boot runes?
> >
> >
> > I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro
> > arm-linux-gnueabihf-gcc 4.7.3
> > as the cross compiler to compile everything. The tree which I pointed
> > towards (in my previous mail)
> > contains the earlyprintk configurations for Jetson-TK1, so I am using
> this
> > command to compile Xen with earlyprintk -
> >
> > make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32
> >
> > I want to update my current stage with Xen, after using this toolchain I
> am
> > able to get Xen to print output
> > on the Jetson-TK1's serial console and Xen is able to boot correctly with
> > all 4 cores in HYP mode.
> >
> > But the problem is when Xen tries to boot the dom0 kernel and transfer
> > control, I receive no output on the serial port.
> > I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled with
> > Xen specific options enabled.
> > Also the same linux kernel is able to boot on the board without Xen.
> >
> > I am passing the dom0 kernel argument to Xen in the /chosen node in the
> > device tree using these commands  -
> >
> > fdt mknod /chosen module
> > fdt set /chosen/module compatible "xen,linux-zimage"
> "xen,multiboot-module"
> > fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize>
> > fdt set /chosen/module bootargs "$bootargs"
>
> I haven't run Xen on ARM yet. But just a random thought:
> Is it possible that you need to provide the console=hvc0 for the boot
> cmdline of dom0?
>
> dom0 needs share the serial port with Xen.


I have added the serial port in the bootargs passed to the kernel. The
bootargs
passed to the dom0 when executing with Xen are the same bootargs which I
pass
when I run the kernel standalone without Xen and at that time I am able to
see the
kernel bootlog and a tty console on the serial port.


> >
> > I am loading Xen at top of the ram and linux and device tree at their
> > default locations (near starting of ram).
> >
> > This is the Xen BootLog which I receive through the earlyprintk serial
> port
> > -
> >
> > - UART enabled -
> > - CPU  booting -
> > - Xen starting in Hyp mode -
> > - Zero BSS -
> > - Setting up control registers -
> > - CPU Init Done -- Turning on paging -
> > - Ready -
> > (XEN) Checking for initrd in /chosen
> > (XEN) RAM: 8000 - ffef
> > (XEN)
> > (XEN) MODULE[0]: 8200 - 8201 Device Tree
> > (XEN) MODULE[1]: 8100 - 8158 Kernel
> > (XEN)  RESVD[0]: 8200 - 8201
> > (XEN)
> > (XEN) Command line: 
> > (XEN) Placing Xen at 0xffc0-0xffe0
> > (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
> > ffc0-ffcf9701
> > (XEN) Xen heap: fa00-fe00 (16384 pages)
> > (XEN) Dom heap: 507648 pages
> > (XEN) Domain heap initialised
> > (XEN) Platform: TEGRA124
> > (XEN) No dtuart path configured
> > (XEN) Bad console= option 'dtuart'
> >  Xen 4.6-unstable
> > (XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc
> > (Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Fri Mar 11 10:09:07 UTC
> 2016
> > (XEN) Latest ChangeSet:
> > (XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev
> 0x3
> > (XEN) 32-bit Execution:
> > (XEN)   Processor Features: 1131:00011011
> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
> > (XEN)

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-12 Thread Meng Xu 
On Sat, Mar 12, 2016 at 9:20 AM, Dushyant Behl
 wrote:
> Hi Julien,
>
> Thanks for the quick reply.
>
> On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall  wrote:
>>
>> Hi Dushyant,
>>
>> On 09/03/2016 20:37, Wei Liu wrote:
>>>
>>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:

 I'm working on a research project with IBM, and I want to run Xen on
 Nvidia
 Tegra Jetson-tk1 board.
 I looked at a post on this mailing list
 (http://lists.xenproject.org/archives/
 html/xen-devel/2015-03/msg01122.html),
 and I am using this git tree -

 git://xenbits.xen.org/people/ianc/xen.git
 and branch  - tegra-tk1-jetson-v1

 But when I try to boot Xen on the board I am not able to see any output
 (even
 with earlyprintk enabled).
 After jumping to Xen the board just resets without showing any output.

 I am using upstream u-boot with non secure mode enabled. I have also
 tested
 booting the Linux kernel on the same setup
 and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm
 enabled.

 Can anyone help me as to what I might have done wrong while using Xen?
>>
>>
>> I never tried to boot Xen on Jetson-TK1 myself.
>>
>> Could you provide the command line you use to compile Xen (with
>> earlyprintk enabled) and the U-boot runes?
>
>
> I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro
> arm-linux-gnueabihf-gcc 4.7.3
> as the cross compiler to compile everything. The tree which I pointed
> towards (in my previous mail)
> contains the earlyprintk configurations for Jetson-TK1, so I am using this
> command to compile Xen with earlyprintk -
>
> make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32
>
> I want to update my current stage with Xen, after using this toolchain I am
> able to get Xen to print output
> on the Jetson-TK1's serial console and Xen is able to boot correctly with
> all 4 cores in HYP mode.
>
> But the problem is when Xen tries to boot the dom0 kernel and transfer
> control, I receive no output on the serial port.
> I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled with
> Xen specific options enabled.
> Also the same linux kernel is able to boot on the board without Xen.
>
> I am passing the dom0 kernel argument to Xen in the /chosen node in the
> device tree using these commands  -
>
> fdt mknod /chosen module
> fdt set /chosen/module compatible "xen,linux-zimage" "xen,multiboot-module"
> fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize>
> fdt set /chosen/module bootargs "$bootargs"

I haven't run Xen on ARM yet. But just a random thought:
Is it possible that you need to provide the console=hvc0 for the boot
cmdline of dom0?

dom0 needs share the serial port with Xen.

>
> I am loading Xen at top of the ram and linux and device tree at their
> default locations (near starting of ram).
>
> This is the Xen BootLog which I receive through the earlyprintk serial port
> -
>
> - UART enabled -
> - CPU  booting -
> - Xen starting in Hyp mode -
> - Zero BSS -
> - Setting up control registers -
> - CPU Init Done -- Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 8000 - ffef
> (XEN)
> (XEN) MODULE[0]: 8200 - 8201 Device Tree
> (XEN) MODULE[1]: 8100 - 8158 Kernel
> (XEN)  RESVD[0]: 8200 - 8201
> (XEN)
> (XEN) Command line: 
> (XEN) Placing Xen at 0xffc0-0xffe0
> (XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
> ffc0-ffcf9701
> (XEN) Xen heap: fa00-fe00 (16384 pages)
> (XEN) Dom heap: 507648 pages
> (XEN) Domain heap initialised
> (XEN) Platform: TEGRA124
> (XEN) No dtuart path configured
> (XEN) Bad console= option 'dtuart'
>  Xen 4.6-unstable
> (XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc
> (Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Fri Mar 11 10:09:07 UTC 2016
> (XEN) Latest ChangeSet:
> (XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 1131:00011011
> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
> (XEN) Extensions: GenericTimer Security
> (XEN)   Debug Features: 02010555
> (XEN)   Auxiliary Features: 
> (XEN)   Memory Model Features: 10201105 4000 0124 02102211
> (XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
> (XEN) Using PSCI-0.1 for SMP bringup
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz
> (XEN) GICv2 initialization:
> (XEN) gic_dist_addr=50041000
> (XEN) gic_cpu_addr=50042000
> (XEN) gic_hyp_addr=50044000
> (XEN) gic_vcpu_addr=50046000
> (XEN) gic_maintenance_irq=25
> (XEN)

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-12 Thread Dushyant Behl 
Hi Julien,

Thanks for the quick reply.

On Thu, Mar 10, 2016 at 10:38 AM, Julien Grall  wrote:

> Hi Dushyant,
>
> On 09/03/2016 20:37, Wei Liu wrote:
>
>> On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
>>
>>> I'm working on a research project with IBM, and I want to run Xen on
>>> Nvidia
>>> Tegra Jetson-tk1 board.
>>> I looked at a post on this mailing list (
>>> http://lists.xenproject.org/archives/
>>> html/xen-devel/2015-03/msg01122.html),
>>> and I am using this git tree -
>>>
>>> git://xenbits.xen.org/people/ianc/xen.git
>>> and branch  - tegra-tk1-jetson-v1
>>>
>>> But when I try to boot Xen on the board I am not able to see any output
>>> (even
>>> with earlyprintk enabled).
>>> After jumping to Xen the board just resets without showing any output.
>>>
>>> I am using upstream u-boot with non secure mode enabled. I have also
>>> tested
>>> booting the Linux kernel on the same setup
>>> and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm
>>> enabled.
>>>
>>> Can anyone help me as to what I might have done wrong while using Xen?
>>>
>>
> I never tried to boot Xen on Jetson-TK1 myself.
>
> Could you provide the command line you use to compile Xen (with
> earlyprintk enabled) and the U-boot runes?
>

I am running a ubuntu trusty schroot and I am using the Ubuntu/Linaro
arm-linux-gnueabihf-gcc 4.7.3
as the cross compiler to compile everything. The tree which I pointed
towards (in my previous mail)
contains the earlyprintk configurations for Jetson-TK1, so I am using this
command to compile Xen with earlyprintk -

make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32

I want to update my current stage with Xen, after using this toolchain I am
able to get Xen to print output
on the Jetson-TK1's serial console and Xen is able to boot correctly with
all 4 cores in HYP mode.

But the problem is when Xen tries to boot the dom0 kernel and transfer
control, I receive no output on the serial port.
I am using Linux 4.1.0 as the dom0 kernel and the kernel is compiled with
Xen specific options enabled.
Also the same linux kernel is able to boot on the board without Xen.

I am passing the dom0 kernel argument to Xen in the /chosen node in the
device tree using these commands  -

fdt mknod /chosen module
fdt set /chosen/module compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module reg <0x0 $kernel_addr_r 0x0 0x$filesize>
fdt set /chosen/module bootargs "$bootargs"

I am loading Xen at top of the ram and linux and device tree at their
default locations (near starting of ram).

This is the Xen BootLog which I receive through the earlyprintk serial port
-

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- CPU Init Done -- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 - ffef
(XEN)
(XEN) MODULE[0]: 8200 - 8201 Device Tree
(XEN) MODULE[1]: 8100 - 8158 Kernel
(XEN)  RESVD[0]: 8200 - 8201
(XEN)
(XEN) Command line: 
(XEN) Placing Xen at 0xffc0-0xffe0
(XEN) Update BOOTMOD_XEN from fd00-fd0f9701 =>
ffc0-ffcf9701
(XEN) Xen heap: fa00-fe00 (16384 pages)
(XEN) Dom heap: 507648 pages
(XEN) Domain heap initialised
(XEN) Platform: TEGRA124
(XEN) No dtuart path configured
(XEN) Bad console= option 'dtuart'
 Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (root@) (arm-linux-gnueabihf-gcc
(Ubuntu/Linaro 4.7.3-11ubuntu1) 4.7.3) debug=y Fri Mar 11 10:09:07 UTC 2016
(XEN) Latest ChangeSet:
(XEN) Processor: 413fc0f3: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x3
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 12000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=50041000
(XEN) gic_cpu_addr=50042000
(XEN) gic_hyp_addr=50044000
(XEN) gic_vcpu_addr=50046000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 192 lines, 4 cpus, secure (IID 043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 32 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- CPU Init Done -- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-09 Thread Julien Grall 

Hi Dushyant,

On 09/03/2016 20:37, Wei Liu wrote:

On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:

I'm working on a research project with IBM, and I want to run Xen on Nvidia
Tegra Jetson-tk1 board.
I looked at a post on this mailing list (http://lists.xenproject.org/archives/
html/xen-devel/2015-03/msg01122.html),
and I am using this git tree -

git://xenbits.xen.org/people/ianc/xen.git
and branch  - tegra-tk1-jetson-v1

But when I try to boot Xen on the board I am not able to see any output (even
with earlyprintk enabled).
After jumping to Xen the board just resets without showing any output.

I am using upstream u-boot with non secure mode enabled. I have also tested
booting the Linux kernel on the same setup
and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm enabled.

Can anyone help me as to what I might have done wrong while using Xen?


I never tried to boot Xen on Jetson-TK1 myself.

Could you provide the command line you use to compile Xen (with 
earlyprintk enabled) and the U-boot runes?


Regards,
--
Julien Grall

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-09 Thread Wei Liu 
CC ARM maintainers

On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
> Hi All,
>  
> I'm working on a research project with IBM, and I want to run Xen on Nvidia
> Tegra Jetson-tk1 board.
> I looked at a post on this mailing list (http://lists.xenproject.org/archives/
> html/xen-devel/2015-03/msg01122.html),
> and I am using this git tree -
>  
> git://xenbits.xen.org/people/ianc/xen.git
> and branch  - tegra-tk1-jetson-v1
>  
> But when I try to boot Xen on the board I am not able to see any output (even
> with earlyprintk enabled).
> After jumping to Xen the board just resets without showing any output.
>  
> I am using upstream u-boot with non secure mode enabled. I have also tested
> booting the Linux kernel on the same setup
> and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm enabled.
>  
> Can anyone help me as to what I might have done wrong while using Xen?
>  
> Thanks,
> Dushyant
> 

> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

[Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-03-08 Thread Dushyant K Behl 
Hi All,
 
I'm working on a research project with IBM, and I want to run Xen on Nvidia Tegra Jetson-tk1 board.
I looked at a post on this mailing list (http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01122.html),
and I am using this git tree -
 
git://xenbits.xen.org/people/ianc/xen.git
and branch  - tegra-tk1-jetson-v1
 
But when I try to boot Xen on the board I am not able to see any output (even with earlyprintk enabled).
After jumping to Xen the board just resets without showing any output.
 
I am using upstream u-boot with non secure mode enabled. I have also tested booting the Linux kernel on the same setup
and Linux 4.0 is able to boot with all 4 cores in HYP mode and kvm enabled.
 
Can anyone help me as to what I might have done wrong while using Xen?
 
Thanks,
Dushyant


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