02-25-2015 02:14 PM
I am trying to boot a ZC706 board from the QSPI. To do this, I have to use petalinux-package --boot (aka bootgen?). There do not appear to be command line options to specify either a device tree blob (*.dtb) or root file system?. AFAICT, the dtb and rootfs are required for linux to boot. That said, from where does petalinux-package --boot get the dtb and rootfs files from?
I am able to boot from the SD card, which requires a BOOT.BIN and image.ub.
The petalinux-package documentation seems to indicate that BOOT.BIN needs only the FSBL, the .Bit bitstream and U-boot. I then assume that image.ub has the dtb, kernel, and rootfs. But for QSPI, I need a single file, so how do I get these in my boot file?
I tried independently using bootgen, and specfiying all the individual files from <PROJECT>images/linux/, but it didn't work either.
Using the bootgen gui in SDK, it looks like perhaps some addresses need to be specified. I will probably go down this path next, but petalinux-package purports to handle creating a boot image and it doesn't appear to be doing do for me.
02-26-2015 09:05 AM
I found this link:
And, although it is for a zc702 board, following the steps in the section about QSPI, I am able to boot via QSPI into U-Boot. I tried putting image.ub where it indicates tke kernel should go. U-boot then errors with something to the effect of "Card did not respond to select voltage." The literature indicates "the partitions used ...could be different, based on the release." My are definitely different. Is there a document that indicates to what and where these are set for the petalinux generated images?
02-26-2015 09:36 AM
The more I study this stuff, the less sense it makes. Per this Xilinx website:
U-Boot needs individual kernel, dtb, and rootfs files:
U-Boot is now by default expecting a uImage Linux kernel image and a ramdisk that is also wrapped with the mkimage utility. It is using the bootm command by default now which also passes the address of the device tree to the Linux kernel. The Linux build process will build a uImage when the uImage target is specified on the make command line.
The mkimage utility is part of u-boot and is placed in the u-boot/tools directory during the build process. It is used to prepend a header onto the specified image such that U-Boot can verify an image was loaded into memory correctly.
Bootm Command Details
The bootm command has the following format:
bootm <Linux uImage address> <mkimage wrapped ramdisk address> <device tree (dtb) address>
The following u-boot commands illustrate loading the Linux kernel uImage, a mkimage wrapped ramdisk, and a device tree into memory from the SD card and then booting the Linux kernel.
u-boot> fatload mmc 0 0x3000000 uImage u-boot> fatload mmc 0 0x2A00000 devicetree.dtb u-boot> fatload mmc 0 0x2000000 uramdisk.image.gz u-boot> bootm 0x3000000 0x2000000 0x2A00000
Which seems to match alot of the various information that shows the use of individual files,
But the petalinux tutorials, and the way that it works currently with the SD card, there are only 2 files BOOT.BIN and image.ub. Assuming that BOOT.BIN has only the fsbl, bit, and u-boot on it, then this implies that uboot knows how to break image.ub into the kernel image, the dtb, and the rootfs.
02-26-2015 11:01 AM
Don't mix the different boot flows. One option is using individual components using U-Boot legacy images (what the wiki describes). The other is FIT images. PetaLinux uses FIT images, thus you don't have those three individual components.
I don't know if it helps you, but I have this little tool that might give a little more insight into your boot.bin: https://github.com/sorenb-xlnx/unbootgen
02-26-2015 01:56 PM
I was able to get my board to boot. I used flashcp to copy BOOT.bin to /dev/mtd0 and image.ub to /dev/mtd2. This didn't work earlier.
Most recently, before I did this, I used petalinux-config, to change all of the uboot settings that I could find from "SD" to "Flash." I think this is what made the difference. In hindsight it seems to make good sense that uboot would need to know where to look for the kernel image.