Welcome, Guest
You have to register before you can post on our site.



Search Forums

(Advanced Search)

Forum Statistics
» Members: 207
» Latest member: Mankirt088
» Forum threads: 71
» Forum posts: 334

Full Statistics

Online Users
There are currently 20 online users.
» 0 Member(s) | 20 Guest(s)

Latest Threads
DomU I/O and Communicatio...
Forum: Public Support
Last Post: ariefgrand
12-12-2017, 09:26 AM
» Replies: 6
» Views: 2,168
DMA from DomU on ZynqMP
Forum: Public Support
Last Post: ariefgrand
12-12-2017, 09:18 AM
» Replies: 2
» Views: 89
DomU and PL on ZCU102 Zyn...
Forum: Public Support
Last Post: Nathan.Studer
12-11-2017, 02:12 PM
» Replies: 1
» Views: 60
Zynq mpsoc dev kit not ab...
Forum: Public Support
Last Post: Nathan.Studer
11-08-2017, 01:24 PM
» Replies: 4
» Views: 2,694
Rebuilding Xen Tools
Forum: Getting Started
Last Post: brettstahlman
11-03-2017, 02:58 PM
» Replies: 2
» Views: 278
SIGBUS: "ttbr address siz...
Forum: Getting Started
Last Post: brettstahlman
11-01-2017, 09:53 PM
» Replies: 8
» Views: 933
FIT Image file handling
Forum: Public Support
Last Post: jarvis_roach
10-16-2017, 12:23 PM
» Replies: 7
» Views: 4,450
Using Petalinux to build ...
Forum: Getting Started
Last Post: brettstahlman
10-13-2017, 04:26 PM
» Replies: 11
» Views: 1,041
Building a custom Xen hyp...
Forum: Getting Started
Last Post: jarvis_roach
10-10-2017, 12:37 PM
» Replies: 3
» Views: 433
XZD Yocto Layer
Forum: Knowledge Base
Last Post: sraxlz
10-02-2017, 07:32 PM
» Replies: 9
» Views: 2,371

  kpartx won't mount root partition
Posted by: jrheisey - 07-11-2017, 09:10 PM - Forum: Public Support - Replies (1)

Here are the steps from the document from DornerWorks Xen-Zynq-Distribution-XZD-Users-Manual.pdf

Quote:1. Create a new clean two partition image.
   $ dd if=/dev/zero of=$RELEASE_DIR/dist/images/sdcard.img bs=1G count=7
   $ echo -e "n\np\n1\n\n+256M\nt\nc\nn\np\n2\n\n\nt\n2\n83\nw\n" | fdisk
2. Install kpartx if it is not already.
   $ sudo apt-get install kpartx
3. Mount both partitions of the image using kpartx.
   sudo kpartx -av $RELEASE_DIR/dist/images/sdcard.img
   sudo mkfs.vfat /dev/mapper/loop1p1
   sudo mkfs.ext4 /dev/mapper/loop1p2

I am using CentOS as a guest of VirtualBox with Windows 7 as the host OS.
I have a couple of issues with the document.
  • For dd I changed the count=7 to count=15 for my larger SD card.
  • The string piped to fdisk did not work out-of-the-box. I needed to manually run fdisk to create the two partitions.
  • The string shows the first partition set to the system ID of 'c' which is 'W95 FAT32 (LBA)'.
          I tried leaving it at the default of '83' for 'Linux' but it did not change the behavior of kpartx.
  • Result of kpartx
         $ sudo kpartx -av $RELEASE_DIR/dist/images/sdcard.img
         [sudo] password for username:
         add map loop0p2 (253:2): 0 14680001 linear /dev/loop0 63
  • mkfs.*: loop1 part of loop1p1 reference is not appropriate for my system because it is mounting as loop0. Easy to compensate.
  • In the two mkfs.vfat command loop0p1 is not mounted at all just loop0p2.
My specific question is why kpartx won't mount the root partition of sdcard.img?

Results from fdisk -l
Disk /media/sf_projects/RDP3/XZD_20161231/dist/images/sdcard.img: 16.1 GB, 16106127360 bytes, 31457280 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x322d1bed
                                                      Device Boot      Start         End      Blocks   Id  System
/media/sf_projects/RDP3/XZD_20161231/dist/images/sdcard.img1            2048     2099199     1048576   83  Linux
/media/sf_projects/RDP3/XZD_20161231/dist/images/sdcard.img2         2099200    31457279    14679040   83  Linux

Print this item

  booting from SD card
Posted by: albanbourge - 06-30-2017, 09:55 AM - Forum: Public Support - Replies (5)

Hello everyone,

My question is probably related with http://xzdforums.dornerworks.com/showthread.php?tid=651, but unfortunately, I was not able to make it work with the solution presented there.
When following the tutorial for booting from SD card, I'm stuck a the booting process.
Here is the log.

Xilinx Zynq MP First Stage Boot Loader
Release 2016.3   Jan  5 2017  -  11:58:09
Platform: Silicon (3.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU9EG
Board Configuration successful
Processor Initialization Done
================= In Stage 2 ============
SD1 with level shifter Boot Mode
SD: rc= 0
File name is BOOT.BIN
SD: Unable to open file BOOT.BIN: 3
Boot Device Initialization failed 0x29
================= In Stage Err ============
Fsbl Error Status: 0x0
I thought about a tool version problem and incompatibility between the boot.bin given and the board I have (ZCU102 rev 1.0 ES2) which is not the same from the tutorial I think because the SW6 configuration shown is not the same (must be 0xE, see UG1182). Hence I tried regenerating the boot.bin with newer SDK version. So I did as the tutorial said for generating a new boot.bin with SDK 2017.2 and get exactly the same error.
Next, I tried to use an FSBL generated with SDK 2017.2. So I started a blank project targeting the board and generated an newer fsbl. I next generated the boot.bin with the same procedure and got :
Xilinx Zynq MP First Stage Boot Loader
Release 2017.2   Jun 30 2017  -  10:53:29
Reset Mode      :       System Reset
Platform: Silicon (3.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU9EG
Board Configuration successful
Processor Initialization Done
================= In Stage 2 ============
SD1 with level shifter Boot Mode
SD: rc= 0
File name is BOOT.BIN
Multiboot Reg : 0x0
Image Header Table Offset 0x8C0
*****Image Header Table Details********
Boot Gen Ver: 0x1020000
No of Partitions: 0x4
Partition Header Address: 0x440
Partition Present Device: 0x0
Initialization Success
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x1800
Data word offset: 0x1800
Total Data word length: 0x1800
Destination Load Address: 0xFFFEA000
Execution Address: 0xFFFEA000
Data word offset: 0x76E0
Partition Attributes: 0x116
Partition 1 Load Success
======= In Stage 3, Partition No:2 =======
UnEncrypted data Length: 0x8
Data word offset: 0x8
Total Data word length: 0x8
Destination Load Address: 0xFFFF0000
Execution Address: 0x0
Data word offset: 0x8EE0
Partition Attributes: 0x116
Partition 2 Load Success
======= In Stage 3, Partition No:3 =======
UnEncrypted data Length: 0x22B80
Data word offset: 0x22B80
Total Data word length: 0x22B80
Destination Load Address: 0x8000000
Execution Address: 0x8000000
Data word offset: 0x8EF0
Partition Attributes: 0x116
Partition 3 Load Success
All Partitions Loaded
================= In Stage 4 ============
Protection configuration applied
 ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x0
NOTICE:  BL31: v1.2(release):2c2b23f
NOTICE:  BL31: Built : 11:58:24, Jan  5 2017

And the console is stuck there. U-boot doesn't show up.

Any idea what I should do ?
Thanks in advance !

Print this item

  XZD Power Management
Posted by: jwolff - 06-27-2017, 06:20 PM - Forum: Public Support - Replies (1)

Hi, I have a few questions about XZD power management.  My goal is to have a configuration in which the full APU-hosted Xen MPSoC system can be suspended to RAM, as described in this Xilinx Wiki page for a Linux-only configuration:
When the APU-hosted Xen system is needed, it would come online much more quickly if it were suspended to RAM than if it needed to boot from scratch.  So, here are my questions:
1) Does the Xen kernel provide a "suspend to RAM" option for itself? 
2) If this is not supported, then is it possible to suspend dom0 in addition to the domU VMs?  Since the Xen kernel boots up very quickly, then suspending all domains might be a good option.
3) Finally, if suspending dom0 and the domUs is possible, can you suspend them to disk (i.e. to non-volatile memory)?  This would allow the APU to be powered off when it is not needed and then boot Xen / restore the VMs more quickly than a normal cold boot.
Thanks very much for your help with these questions!

Print this item

  DomU I/O and Communication
Posted by: pello.heriz - 06-19-2017, 07:07 AM - Forum: Public Support - Replies (6)


I'm very interested in knowing how to assign specific HW to each one of the running OS-s if I'm working with Xen hypervisor. Is it possible? Where do I need to specify this?

On the other hand, I also would like to know, how would the different OS-s running under Xen hypervisor communicate between them. I.e.: an application running over Linux (i.e.: Docker) and FreeRTOS.

Finally, it would be interesting for me too, to know how to debug the behavior of an OS running under Xen (i.e.: FreeRTOS) in the real MPSoC board.

Any answer would be helpful,


Print this item

  XZD Yocto Layer
Posted by: Nathan.Studer - 04-12-2017, 03:23 PM - Forum: Knowledge Base - Replies (9)

In preparation for the 2017.1 XZD release, the XZD Yocto Layer has been made publicly available.  This Yocto Layer can currently be used to generate XZD kernel images and root filesystems with the 2016.4 version of XSDK.

The layer and instructions for using it can be found in github at https://github.com/dornerworks/meta-xzd .  A repo manifest which simplifies the process can also be found in github at https://github.com/dornerworks/xzd-yocto-manifests .


Print this item

  Yocto image as domU
Posted by: pello.heriz - 04-07-2017, 09:28 AM - Forum: Public Support - Replies (12)

Is it possible to add an image created myself with Yocto as a dom1 or dom2 guest? If the answer is yes, which are the steps I need to follow to add this image as a guest?

Best regards,

Print this item

  Trouble overriding Petalinux u-boot environment
Posted by: brettstahlman - 04-06-2017, 09:44 PM - Forum: Getting Started - Replies (11)

I'm struggling to find documentation on the proper way to override boot environment settings without rebuilding u-boot. The default environment is wrong for me: for instance, it looks for certain files (e.g., "uEnv.txt") on a fat boot partition whose partition id is given by $partid, which is hardcoded to 0 in the default environment, but needs to be 1. Although the u-boot docs don't mention "uEnv.txt" specifically, a number of internet sources seemed to suggest it provides a mechanism for overriding the default environment. Unfortunately, the commands in the environment for loading uEnv.txt expect to find it on partition $partid, which means I can't use it to fix the incorrect environment setting.

Other online sources suggest that "uboot.env" is a special file from which environment variables are automatically read. This file appears to be a (mostly) plain text file with a CRC checksum, which can be written with saveenv from the u-boot shell. Accordingly, I made the desired env changes in the shell, then used saveenv to save. That seemed to work, in the sense that my changes were persisted in a "uboot.env" on my boot partition. Unfortunately, it appears that the $partid variable saved in the file is getting clobbered somehow on reboot: i.e., I can see that it's 1 in the file, but after a reboot, "echo $partid" shows 0.

The lack of documentation on these mechanisms is very frustrating. Can anyone point me to documentation on how the various override mechanisms are supposed to work? Also, if I didn't mind rebuilding u-boot, what would be the recommended way to set the default environment? For instance, how would I change the default sd boot command?

Brett S.

Print this item

  Kernel panic when launching QEMU
Posted by: pello.heriz - 04-06-2017, 07:17 AM - Forum: Public Support - Replies (1)

Hi all,

-Host: Ubuntu 16.04 (in Virtual Box)
-Petalinux and SDK version: 2016.3
-XZD version: XZD20161231

I have followed the steps shown in the last XZD user manual (january 6, 2017) to launch Xen on QEMU, but I'm having some problems. When I execute the command to launch the image on QEMU, sometimes (1 / 10) the launching seems to be good, but in the rest of the cases a kernel panic occurs. This is how the kernel panic looks like:

[   49.994179] Call trace:
[   49.996072] [<ffffff8008088840>] dump_backtrace+0x0/0x198
[   49.996982] [<ffffff80080889ec>] show_stack+0x14/0x20
[   49.997567] [<ffffff80080bf910>] sched_show_task+0x98/0xf8
[   49.998254] [<ffffff80080e3d00>] rcu_check_callbacks+0x740/0x748
[   49.998755] [<ffffff80080e6a4c>] update_process_times+0x3c/0x68
[   49.999230] [<ffffff80080f5b3c>] tick_sched_handle.isra.5+0x3c/0x50
[   50.001318] [<ffffff80080f5b94>] tick_sched_timer+0x44/0x90
[   50.001933] [<ffffff80080e7400>] __hrtimer_run_queues+0xf0/0x178
[   50.002557] [<ffffff80080e7790>] hrtimer_interrupt+0x98/0x1c8
[   50.003283] [<ffffff8008633af0>] arch_timer_handler_virt+0x30/0x40
[   50.003966] [<ffffff80080dab68>] handle_percpu_devid_irq+0x78/0xa0
[   50.005726] [<ffffff80080d635c>] generic_handle_irq+0x24/0x38
[   50.006402] [<ffffff80080d6694>] __handle_domain_irq+0x5c/0xb8
[   50.007023] [<ffffff80080814bc>] gic_handle_irq+0x64/0xc0
[   50.007603] Exception stack(0xffffffc0328b7e40 to 0xffffffc0328b7f60)
[   50.008420] 7e40: 0000000000000000 0000000000000000 0000000000000001 0000000000000001
[   50.009126] 7e60: 00000000000001c0 0100000000000000 00297c1e00000000 00000000ffff0918
[   50.009731] 7e80: ffffffc0328ac9e0 ffffffc0328b4000 0000000000000780 0000000000000001
[   50.010877] 7ea0: 0000000000000001 dead000000000200 dead000000000100 ffffffbe00000000
[   50.011673] 7ec0: ffffff8008ad9000 ffffffc032809d28 000000000000000c 0000000000000000
[   50.013353] 7ee0: ffffffc0328b4000 ffffff8008ad9000 ffffffc0328b4000 ffffff8008ad9000
[   50.014122] 7f00: ffffff8008ab7ff0 ffffff8008b58000 ffffffc0328b4000 0000000000000000
[   50.014904] 7f20: 0000000000000000 ffffffc0328b7f60 ffffff800808567c ffffffc0328b7f60
[   50.015693] 7f40: ffffff8008085680 0000000060000145 ffffffc0328b7f70 7fffffffffffffff
[   50.016527] [<ffffff8008084720>] el1_irq+0xa0/0x100
[   50.017201] [<ffffff8008085680>] arch_cpu_idle+0x10/0x18
[   50.017919] [<ffffff80080cf36c>] cpu_startup_entry+0x144/0x1d8
[   50.019187] [<ffffff800808df90>] secondary_start_kernel+0x170/0x1c8
[   50.020968] [<000000002008184c>] 0x2008184c
[   50.022011] rcu_sched kthread starved for 5247 jiffies! g583 c582 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x100
[   50.023441] rcu_sched       W ffffff8008085b1c     0     7      2 0x00000000
[   50.024350] Call trace:
[   50.024641] [<ffffff8008085b1c>] __switch_to+0xc4/0xd0
[   50.025238] [<ffffff80087d6734>] __schedule+0x19c/0x588
[   50.025721] [<ffffff80087d6b50>] schedule+0x30/0x90
[   50.026034] [<ffffff80087d93e8>] schedule_timeout+0x108/0x1b0
[   50.028872] [<ffffff80080e2e10>] rcu_gp_kthread+0x368/0x7a0
[   50.029466] [<ffffff80080b60e8>] kthread+0xd0/0xe8
[   50.029889] [<ffffff8008084dd0>] ret_from_fork+0x10/0x40

The command that I'm using to launch QEMU is the one shown in the user manual.

Anyway, I have observe that even when the image booting seems to be correct and I arrive into Dom0 terminal, the system never mounts /proc, /sys and /debug directories, and even if the kernel panic hasn't happened yet, it can happens also when I try to run a xl command or simply when Dom0 or the guest Dom1 is running. 

Here you have how the system never mounts the mentioned directories:

Starting network...
Starting Xilinx Xen Boot Scripts: mount: mounting none on /proc failed: Device or resource busy
mount: mounting none on /sys/ failed: Device or resource busy
mount: mounting none on /debug/ failed: No such file or directory

Finally, I can also observe that sometimes the launching process get stuck in some step and doesn't appear any kernel panic as for example in the next case:

tarting network...
Starting Xilinx Xen Boot Scripts: mount: mounting none on /proc failed: Device or resource busy
mount: mounting none on /sys/ failed: Device or resource busy
mount: mounting none on /debug/ failed: No such file or directory
[   42.827299] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   44.620198] macb ff0e0000.ethernet eth0: unable to generate target frequency: 25000000 Hz
[   44.621754] macb ff0e0000.ethernet eth0: link up (100/Half)
[   44.679022] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   50.693458] xenbr0: port 1(eth0) entered blocking state
[   50.696538] xenbr0: port 1(eth0) entered disabled state
[   50.725696] device eth0 entered promiscuous mode
udhcpc (v1.23.1) started
[   51.648543] xenbr0: port 1(eth0) entered blocking state
[   51.649553] xenbr0: port 1(eth0) entered forwarding state
Sending discover...
Sending select for
Lease of obtained, lease time 86400
deleting routers

Any answer will be welcome,
Best regards,

Print this item

  What type of dom0 Image does Xen expect/require?
Posted by: brettstahlman - 03-15-2017, 10:42 PM - Forum: Public Support - Replies (4)

Inspection of the build artifacts from a petalinux-build shows a vmlinux whose <stext> section starts at 0x80040, with an unconditional branch to 0x80040 at start of _text section @ 0x80000. When I try to boot a dom0 kernel built with buildroot, boot simply hangs. Don't know whether this is the problem, but I've noticed that the buildroot-generated vmlinux file used to create the dom0 Image has PE and COFF headers at the 0x80000 address prior to the stext section. (The code at 0x80000 is an add, followed by an unconditional branch past the headers to <stext>.) First of all, can anyone provide a link to documentation on what exactly Xen is expecting? I've seen several boot examples, but I'm having trouble locating documentation on the applicable boot protocol.

I'm wondering whether there's something I could modify here...

fatload mmc 0:1 0x80000 Image
fdt set /chosen/dom0 reg <0 0x80000 0x$filesize>

...which would allow me to boot a non-petalinux Image (e.g., one that has the standard EFI boot stub at 0x80000).

What is the "secret sauce" that allows the petalinux Image to boot where the buildroot Image hangs? (Note that I've booted the buildroot Image successfully without Xen...)

Print this item

  Question on format of dom0 kernel image in XZD distribution
Posted by: brettstahlman - 03-14-2017, 06:40 PM - Forum: Public Support - No Replies

Thus far, I've had no need to rebuild the default linux kernel that ships with XZD:


The linux "file" utility calls this file "data". I have another dom0 kernel I'm attempting to boot (unsuccessfully), which the file utility reports as...
"MS-DOS executable, MZ for MS-DOS"

As best I can tell, the latter image is an objcopy'd version of the uncompressed linux kernel executable "vmlinux".

When I attempt to boot using this non-XZD kernel file, the boot simply hangs at the end of the Xen kernel load, at the point where the linux kernel would normally start booting. Clearly, though the files are both named "Image", they are different formats, and apparently, whereas the one included in XZD is suitable for loading at 0x80000, the one corresponding to vmlinux is not. What is the format of dist/images/linux/Image? How is it built? Any light you can shed on what format(s) the Xen kernel can handle would be greatly appreciated. Also appreciated would be links to any relevant documentation.

*** Update ***
I've noticed another Image file in the XZD distribution whose format is similar to the one I've been unable to boot:


This image also has the "MS-DOS executable, MZ for MS-DOS" format, and is significantly larger than the "<project>/images/linux/Image" created by petalinux-build. I suspect that this file is meant to be loaded as an executable from disk, whereas the smaller "data" Image is meant to be loaded directly to RAM by the boot script, and eventually jumped into by the Xen kernel. If so, how can I create the smaller "data" file (the one suitable for load from boot script) from vmlinux? I'm thinking it involves objcopy, but even when I run petalinux-build with verbose option (-v), the full objcopy command doesn't appear in the output, so I can't tell which options are required...

*** Update ***
I've now used objdump to examine both source vmlinux images, and I think I can see why the Image produced from one boots and the other doesn't. The one that boots has an unconditional branch at the start of the _text section (0x80000) to section <stext> (0x80040). The vmlinux whose corresponding Image doesn't boot has the PE/COFF headers at the beginning, and the <stext> section at a significantly higher address (after all the headers and a bunch of NOPs). What exactly is the Xen kernel expecting to find at 0x80000? Do I need to build a vmlinux without the PE/COFF headers, or should I just modify my build process to strip certain header sections out?

Print this item