Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Qemu launches but boot hangs before login prompt
#11
(02-24-2017, 12:16 AM)Nathan.Studer Wrote:
(02-23-2017, 11:22 PM)jarvis_roach Wrote: The -hw-dtb directive is actually used for QEMU to know what devices to emulate; QEMU understands it, not sure if the semantics are understood by Xen and Linux.  'xen.dtb' is the device-tree that Xen and Dom0 use, with all the semantics that they expect.

From unpleasant experience I can tell you that the QEMU device tree and system device tree (i.e. xen.dtb) are not interchangeable.  If you give Qemu the wrong device tree it will refuse to run and complain about device tree syntax errors.  If you give Xen/Linux the wrong device tree, the system will hang when u-boot makes the jump to the hypervisor/kernel.

     Nate

Makes sense. But I'm a bit confused about what needs to be specified explicitly in the qemu command line, and what is simply assumed to be in certain locations (e.g., the directory specified with -tftp). This is the command line I've been able to boot (copied from Xen Zynq User's Manual)...

Code:
qemu-system-aarch64 -L $RELEASE_DIR/etc/qemu -M arm-generic-fdt -
device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 -serial mon:stdio -serial
/dev/null -display none -device loader,file=$RELEASE_DIR/dist/images/linux/bl31.elf,cpu=0 -
device loader,file=$RELEASE_DIR/dist/images/linux/u-boot.elf -gdb tcp::9000 -tftp /tftpboot
-drive file=$RELEASE_DIR/dist/images/dom0.img,format=raw,if=sd -redir tcp:2222::22 -net
nic,vlan=0 -net user,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -hw-dtb
$RELEASE_DIR/dist/images/linux/zynqmp-qemu-arm.dtb -pflash
$RELEASE_DIR/dist/images/linux/nand0.qcow2

...and here are a few points of confusion:
  • Why are files like bl31.elf and u-boot.elf, which are present in the distribution tree and specified on the command line, also copied into the /tftpboot dir? I understand why QEMU and Linux would require different versions of the DTB, but I'm assuming there's only one instance of u-boot involved. Is the point of using the loader "device" for these 2 files simply that it lets us force them to be loaded at startup (and in the case of bl31.elf, loaded on a specific CPU)?
  • Does the -tftp option cause QEMU to look for certain files in the tftpboot dir? If so, where is this documented?
  • Where is the Xen hypervisor kernel loaded from? I have a xen.ub in my /tftpboot dir. Is that it, and if so, is that extension special to u-boot? E.g., Will it just run any valid *.ub files in the tftp dir, or is this a special, Xen-aware version of u-boot?
  • Why is it necessary to write 0x8000000e to address 0xfd1a0104?
  • Why is the -pflash option needed? Is it storing boot options or something?
It's probably clear from the questions above that I could really benefit from some detailed documentation on the boot process (preferably tailored towards XZD). Does such documentation exist? I've looked through the QEMU man page and the Xilinx Xen Zynq User Manual. The latter has some good step-by-step instructions for certain boot configurations, but I think I need more of the concepts/theory behind it so that I can tailor my own boot strategy. For instance, I'd like to load some DomU's automatically after Dom0 has booted.
Reply
#12
(02-25-2017, 11:31 PM)brettstahlman Wrote: For instance, I'd like to load some DomU's automatically after Dom0 has booted.

How to start guests automatically.

     Nate
Reply
#13
(02-25-2017, 11:31 PM)brettstahlman Wrote:
(02-24-2017, 12:16 AM)Nathan.Studer Wrote:
(02-23-2017, 11:22 PM)jarvis_roach Wrote: The -hw-dtb directive is actually used for QEMU to know what devices to emulate; QEMU understands it, not sure if the semantics are understood by Xen and Linux.  'xen.dtb' is the device-tree that Xen and Dom0 use, with all the semantics that they expect.

From unpleasant experience I can tell you that the QEMU device tree and system device tree (i.e. xen.dtb) are not interchangeable.  If you give Qemu the wrong device tree it will refuse to run and complain about device tree syntax errors.  If you give Xen/Linux the wrong device tree, the system will hang when u-boot makes the jump to the hypervisor/kernel.

     Nate

Makes sense. But I'm a bit confused about what needs to be specified explicitly in the qemu command line, and what is simply assumed to be in certain locations (e.g., the directory specified with -tftp). This is the command line I've been able to boot (copied from Xen Zynq User's Manual)...

Code:
qemu-system-aarch64 -L $RELEASE_DIR/etc/qemu -M arm-generic-fdt -
device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 -serial mon:stdio -serial
/dev/null -display none -device loader,file=$RELEASE_DIR/dist/images/linux/bl31.elf,cpu=0 -
device loader,file=$RELEASE_DIR/dist/images/linux/u-boot.elf -gdb tcp::9000 -tftp /tftpboot
-drive file=$RELEASE_DIR/dist/images/dom0.img,format=raw,if=sd -redir tcp:2222::22 -net
nic,vlan=0 -net user,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -hw-dtb
$RELEASE_DIR/dist/images/linux/zynqmp-qemu-arm.dtb -pflash
$RELEASE_DIR/dist/images/linux/nand0.qcow2

...and here are a few points of confusion:
  • Why are files like bl31.elf and u-boot.elf, which are present in the distribution tree and specified on the command line, also copied into the /tftpboot dir? I understand why QEMU and Linux would require different versions of the DTB, but I'm assuming there's only one instance of u-boot involved. Is the point of using the loader "device" for these 2 files simply that it lets us force them to be loaded at startup (and in the case of bl31.elf, loaded on a specific CPU)?
  • Does the -tftp option cause QEMU to look for certain files in the tftpboot dir? If so, where is this documented?
  • Where is the Xen hypervisor kernel loaded from? I have a xen.ub in my /tftpboot dir. Is that it, and if so, is that extension special to u-boot? E.g., Will it just run any valid *.ub files in the tftp dir, or is this a special, Xen-aware version of u-boot?
  • Why is it necessary to write 0x8000000e to address 0xfd1a0104?
  • Why is the -pflash option needed? Is it storing boot options or something?
It's probably clear from the questions above that I could really benefit from some detailed documentation on the boot process (preferably tailored towards XZD). Does such documentation exist? I've looked through the QEMU man page and the Xilinx Xen Zynq User Manual. The latter has some good step-by-step instructions for certain boot configurations, but I think I need more of the concepts/theory behind it so that I can tailor my own boot strategy. For instance, I'd like to load some DomU's automatically after Dom0 has booted.

Brett,

You are correct, with QEMU, the boot files (bl31.elf and u-boot.elf) are loaded into the emulated chip's memory via the command line arguments and should not need to be copied to /tftpboot. I took a quick look through the UM and didn't find where it would be telling you to do so, can you tell me what section is telling you to do that so we can correct that in future versions?

-tftp tells QEMU what root directory it should use for the TFTP service it provides for the emulated network. http://download.qemu-project.org/qemu-doc.html is a good place to look up QEMU command line options and capabilities.

The Xen kernel, xen.ub, is TFTP'd by u-boot. The u-boot version is ZUS+ specific (meaning there are some specific Xilinx driver updates) but not specifically "Xen-aware", so you can use it as you would any other u-boot image. See http://www.denx.de/wiki/U-Boot for more details.

0xFD1A0104 is the Z US+ RST_FPD_APU register, writing 0x8000000e keep APU cores 3,2,1 in reset while taking core 0 out of reset. See https://www.xilinx.com/html_docs/registe...sters.html and other Xilinx documentation for more details.

The pflash is used to provide storage backing for the emulated flash.

For QEMU, the boot process is that via command line bl31.elf and u-boot.elf are loaded into memory and bl31.elf is run, which passes control to u-boot.elf. U-boot is configured to TFTP boot, grabbing xen.ub, xen.dtb, and Image from the /tftpboot/ directory.

For ZCU102, there are a few different combination you can use use.  You can boot with JTAG, for which you have to populate the memory with the FSBL, BL31, and U-Boot (kind of like with QEMU) using JTAG and then run FSBL, which runs BL31, which runs u-boot, which then can either TFTP the xen.ub, Image, and xen.dtb files over like with QEMU, or if an SD card is present and formatted/populated properly, load those files from the SD card instead. If you SD card is set up with a boot.bin file, you can set the dip switches on the ZCU102 board and boot from that, which will load and run the FSBL, BL31, and U-boot, from the storage media instead, and then you can choose to continue booting via TFTP or from files on the SD card. Instructions for doing so are in the User's Manual section 4.2.

Regards,

-Jarvis
Reply
#14
(02-27-2017, 04:30 PM)jarvis_roach Wrote:
(02-25-2017, 11:31 PM)brettstahlman Wrote:
(02-24-2017, 12:16 AM)Nathan.Studer Wrote:
(02-23-2017, 11:22 PM)jarvis_roach Wrote: The -hw-dtb directive is actually used for QEMU to know what devices to emulate; QEMU understands it, not sure if the semantics are understood by Xen and Linux.  'xen.dtb' is the device-tree that Xen and Dom0 use, with all the semantics that they expect.

From unpleasant experience I can tell you that the QEMU device tree and system device tree (i.e. xen.dtb) are not interchangeable.  If you give Qemu the wrong device tree it will refuse to run and complain about device tree syntax errors.  If you give Xen/Linux the wrong device tree, the system will hang when u-boot makes the jump to the hypervisor/kernel.

     Nate

Makes sense. But I'm a bit confused about what needs to be specified explicitly in the qemu command line, and what is simply assumed to be in certain locations (e.g., the directory specified with -tftp). This is the command line I've been able to boot (copied from Xen Zynq User's Manual)...

Code:
qemu-system-aarch64 -L $RELEASE_DIR/etc/qemu -M arm-generic-fdt -
device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 -serial mon:stdio -serial
/dev/null -display none -device loader,file=$RELEASE_DIR/dist/images/linux/bl31.elf,cpu=0 -
device loader,file=$RELEASE_DIR/dist/images/linux/u-boot.elf -gdb tcp::9000 -tftp /tftpboot
-drive file=$RELEASE_DIR/dist/images/dom0.img,format=raw,if=sd -redir tcp:2222::22 -net
nic,vlan=0 -net user,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -hw-dtb
$RELEASE_DIR/dist/images/linux/zynqmp-qemu-arm.dtb -pflash
$RELEASE_DIR/dist/images/linux/nand0.qcow2

...and here are a few points of confusion:
  • Why are files like bl31.elf and u-boot.elf, which are present in the distribution tree and specified on the command line, also copied into the /tftpboot dir? I understand why QEMU and Linux would require different versions of the DTB, but I'm assuming there's only one instance of u-boot involved. Is the point of using the loader "device" for these 2 files simply that it lets us force them to be loaded at startup (and in the case of bl31.elf, loaded on a specific CPU)?
  • Does the -tftp option cause QEMU to look for certain files in the tftpboot dir? If so, where is this documented?
  • Where is the Xen hypervisor kernel loaded from? I have a xen.ub in my /tftpboot dir. Is that it, and if so, is that extension special to u-boot? E.g., Will it just run any valid *.ub files in the tftp dir, or is this a special, Xen-aware version of u-boot?
  • Why is it necessary to write 0x8000000e to address 0xfd1a0104?
  • Why is the -pflash option needed? Is it storing boot options or something?
It's probably clear from the questions above that I could really benefit from some detailed documentation on the boot process (preferably tailored towards XZD). Does such documentation exist? I've looked through the QEMU man page and the Xilinx Xen Zynq User Manual. The latter has some good step-by-step instructions for certain boot configurations, but I think I need more of the concepts/theory behind it so that I can tailor my own boot strategy. For instance, I'd like to load some DomU's automatically after Dom0 has booted.

Brett,

You are correct, with QEMU, the boot files (bl31.elf and u-boot.elf) are loaded into the emulated chip's memory via the command line arguments and should not need to be copied to /tftpboot. I took a quick look through the UM and didn't find where it would be telling you to do so, can you tell me what section is telling you to do that so we can correct that in future versions?

-tftp tells QEMU what root directory it should use for the TFTP service it provides for the emulated network. http://download.qemu-project.org/qemu-doc.html is a good place to look up QEMU command line options and capabilities.

The Xen kernel, xen.ub, is TFTP'd by u-boot. The u-boot version is ZUS+ specific (meaning there are some specific Xilinx driver updates) but not specifically "Xen-aware", so you can use it as you would any other u-boot image. See http://www.denx.de/wiki/U-Boot for more details.

0xFD1A0104 is the Z US+ RST_FPD_APU register, writing 0x8000000e keep APU cores 3,2,1 in reset while taking core 0 out of reset. See https://www.xilinx.com/html_docs/registe...sters.html and other Xilinx documentation for more details.

The pflash is used to provide storage backing for the emulated flash.

For QEMU, the boot process is that via command line bl31.elf and u-boot.elf are loaded into memory and bl31.elf is run, which passes control to u-boot.elf. U-boot is configured to TFTP boot, grabbing xen.ub, xen.dtb, and Image from the /tftpboot/ directory.

For ZCU102, there are a few different combination you can use use.  You can boot with JTAG, for which you have to populate the memory with the FSBL, BL31, and U-Boot (kind of like with QEMU) using JTAG and then run FSBL, which runs BL31, which runs u-boot, which then can either TFTP the xen.ub, Image, and xen.dtb files over like with QEMU, or if an SD card is present and formatted/populated properly, load those files from the SD card instead. If you SD card is set up with a boot.bin file, you can set the dip switches on the ZCU102 board and boot from that, which will load and run the FSBL, BL31, and U-boot, from the storage media instead, and then you can choose to continue booting via TFTP or from files on the SD card. Instructions for doing so are in the User's Manual section 4.2.

Regards,

-Jarvis

Jarvis,
Thanks! That's exactly what I was looking for!

Step 11 of section 3.3 in the UM is the one that copies bl31.elf and u-boot.elf to the /tftpdir. I guess it was an incidental copy, but I assumed it was intentional - i.e., that these files were needed for download via TFTP.

So U-Boot loads the Xen kernel by default simply because xen.ub is the only valid U-Boot image in /tftpdir?

So pflash starts out as an empty virtual storage device, which I could create with a command such as the following?
Code:
qemu-img create -f qcow2 nand0.qcow2 200K

Does the size need to match a specific flash device on the ZCU102?

Btw, do you know of a way to get the U-Boot documentation as a single file? (The multi-page HTML format doesn't lend itself to searches...)

Thanks,
Brett S.

(02-27-2017, 01:45 PM)Nathan.Studer Wrote:
(02-25-2017, 11:31 PM)brettstahlman Wrote: For instance, I'd like to load some DomU's automatically after Dom0 has booted.

How to start guests automatically.

     Nate

Thanks!
Brett S.
Reply
#15
"You are correct, with QEMU, the boot files (bl31.elf and u-boot.elf) are loaded into the emulated chip's memory via the command line arguments."

I wanted to use QEMU to boot from an sd card image I've been able to boot successfully on the ZCU102. Accordingly, I created an image using dd, used losetup and fdisk to partition, created a boot partition containing BOOT.bin and an ext4 partition with linux system, and finally, copied all the files into these partitions so that the image looks just like the sd card I've been booting from.

I've tried both "-drive file=some.img,if=sd" and "-sd some.img". In both cases, I can access the 2 partitions from within the U-Boot shell: e.g., with ls mmc 0:1 and ls mmc 0:2. But I can't even get to the U-Boot shell without loading bl31.elf and u-boot.elf explicitly from the command line, even though both bl31 and u-boot exist in the boot partition of the emulated sd card. How do I force the emulated zcu102 to use the BOOT.bin on the emulated sd, just as it does when I boot on the actual board?

Thanks,
Brett S.
Reply
#16
From the Xilinx documentation, I had found that you still need to put the FSBL into memory, I think because QEMU isn't emulating the PMU and CSU's the bootROM behavior. Also, there are some boot modes and other SD card parameters that you need to set. Below is a sample of what I've used to do what you're talking about, it's something we're looking at adding for the release next month.

qemu-system-aarch64 -L /opt/Xilinx/petalinux-v2016.3-final/etc/qemu -M arm-generic-fdt -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 -serial monConfusedtdio -serial /dev/null -display none -gdb tcp::9000 -tftp /tftpboot -redir tcp:2222::22 -net nic,vlan=0 -net user,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -device loader,addr=0xFD5F0018,data=0x0000001f,data-len=4 -device loader,addr=0xff240000,data=0x00000492,data-len=4 -device loader,addr=0xff240004,data=0x00000492,data-len=4 -hw-dtb /home/jarvis/XZD/Xilinx-ZynqMP/images/linux/zynqmp-qemu-arm.dtb -pflash /home/jarvis/XZD/Xilinx-ZynqMP/images/linux/nand0.qcow2 -device loader,file=/home/jarvis/XZD/Xilinx-ZynqMP/images/linux/zynqmp_fsbl.elf,cpu=0 -drive file=qemu_sd2.img,format=raw,if=sd,index=1 -boot mode=5
Reply
#17
(02-28-2017, 02:53 AM)jarvis_roach Wrote: From the Xilinx documentation, I had found that you still need to put the FSBL into memory, I think because QEMU isn't emulating the PMU and CSU's the bootROM behavior. Also, there are some boot modes and other SD card parameters that you need to set. Below is a sample of what I've used to do what you're talking about, it's something we're looking at adding for the release next month.

qemu-system-aarch64 -L /opt/Xilinx/petalinux-v2016.3-final/etc/qemu -M arm-generic-fdt -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4   -serial monConfusedtdio -serial /dev/null -display none -gdb tcp::9000  -tftp /tftpboot  -redir tcp:2222::22 -net nic,vlan=0 -net user,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -device loader,addr=0xFD5F0018,data=0x0000001f,data-len=4 -device loader,addr=0xff240000,data=0x00000492,data-len=4 -device loader,addr=0xff240004,data=0x00000492,data-len=4 -hw-dtb /home/jarvis/XZD/Xilinx-ZynqMP/images/linux/zynqmp-qemu-arm.dtb -pflash /home/jarvis/XZD/Xilinx-ZynqMP/images/linux/nand0.qcow2 -device loader,file=/home/jarvis/XZD/Xilinx-ZynqMP/images/linux/zynqmp_fsbl.elf,cpu=0 -drive file=qemu_sd2.img,format=raw,if=sd,index=1 -boot mode=5

Excellent! Do you have a link to the Xilinx documentation you mentioned? All I was able to find on those addresses was a TRM, which associated 0xFD5F_0000 with the SMMU and 0xFF24_0000 with "IOU SLCR for AXI read/write protection configuration". Also, I couldn't find any documentation on -boot mode=5 option.

At any rate, the command you listed works for me, but only if I use the fsbl.elf in the Xilinx SDK. When I tried the zynq_fsbl.elf in my XZD distribution, the boot hung at...

Code:
Running on A53-0 (64-bit) Processor, Device Name: ...



Not sure what the difference is between these 2 FSBL executables...
Reply
#18
My guess is either some kind of version incompatibility, or some kind of security compatibility.
Reply
#19
(02-28-2017, 05:24 PM)jarvis_roach Wrote: My guess is either some kind of version incompatibility, or some kind of security compatibility.

Ok. Thanks.
Reply
#20
(02-28-2017, 05:22 PM)brettstahlman Wrote:
(02-28-2017, 02:53 AM)jarvis_roach Wrote: From the Xilinx documentation, I had found that you still need to put the FSBL into memory, I think because QEMU isn't emulating the PMU and CSU's the bootROM behavior. Also, there are some boot modes and other SD card parameters that you need to set. Below is a sample of what I've used to do what you're talking about, it's something we're looking at adding for the release next month.

qemu-system-aarch64 -L /opt/Xilinx/petalinux-v2016.3-final/etc/qemu -M arm-generic-fdt -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4   -serial monConfusedtdio -serial /dev/null -display none -gdb tcp::9000  -tftp /tftpboot  -redir tcp:2222::22 -net nic,vlan=0 -net user,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -net nic,vlan=0 -device loader,addr=0xFD5F0018,data=0x0000001f,data-len=4 -device loader,addr=0xff240000,data=0x00000492,data-len=4 -device loader,addr=0xff240004,data=0x00000492,data-len=4 -hw-dtb /home/jarvis/XZD/Xilinx-ZynqMP/images/linux/zynqmp-qemu-arm.dtb -pflash /home/jarvis/XZD/Xilinx-ZynqMP/images/linux/nand0.qcow2 -device loader,file=/home/jarvis/XZD/Xilinx-ZynqMP/images/linux/zynqmp_fsbl.elf,cpu=0 -drive file=qemu_sd2.img,format=raw,if=sd,index=1 -boot mode=5

Excellent! Do you have a link to the Xilinx documentation you mentioned? All I was able to find on those addresses was a TRM, which associated 0xFD5F_0000 with the SMMU and 0xFF24_0000 with "IOU SLCR for AXI read/write protection configuration". Also, I couldn't find any documentation on -boot mode=5 option.

At any rate, the command you listed works for me, but only if I use the fsbl.elf in the Xilinx SDK. When I tried the zynq_fsbl.elf in my XZD distribution, the boot hung at...

Code:
Running on A53-0 (64-bit) Processor, Device Name: ...



Not sure what the difference is between these 2 FSBL executables...

For the record... I'm thinking this AR may explain why I was unable to boot in QEMU with the FSBL on my SD card.

Also, this wiki article seems to shed some light on the use of -boot mode=N (though I still haven't found it documented anywhere). Looks as though modes 1, 4, and 5 select QSPI, NAND and SD for booting, respectively.[url=http://www.wiki.xilinx.com/Zynq+UltraScale+MPSoC+Non+Secure+Boot][/url]
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)