06-14-2017 08:06 AM
I'm attempting to boot my own linux build on ultraZed from an SD card (similar to this). I'm fairly new to configuring boot, so may be doing something not intelligent.
I create the project, configure root fs type (as pg 41 ug1144) and dtb image settings (as linked post) to SD card. Make a small change to the rootfs (allow TCF debugging dropbear) and build it all.
My problem I think is in the packaging. I've tried various versions of the following command to build the BOOT.BIN.
petalinux-package --boot --fsbl zynqmp_fsbl.elf --fpga myBits.bit --pmufw pmufw.elf --u-boot --kernel
Regardless of what I do after my FSBL and u-boot, it boots the Linux that came on the board from Avnet. The build date of the FSBL and the FPGA lights shows me it's using my SD card (formated with 4mb empty before and 2 partitions; fat32 and ext4), but then loads the pre-built linux.
U-Boot 2017.01 (Jun 14 2017 - 11:32:21 +0100) Xilinx ZynqMP ZCU102 revB I2C: Error, wrong i2c adapter 0 max 0 possible Error, wrong i2c adapter 0 max 0 possible ready DRAM: 2 GiB EL Level: EL2 Chip ID: xczu3eg MMC: sdhci@ff160000: 0 (eMMC), sdhci@ff170000: 1 (SD) SF: Detected n25q256a with page size 512 Bytes, erase size 128 KiB, total 64 MiB Error, wrong i2c adapter 0 max 0 possible Error, wrong i2c adapter 0 max 0 possible In: serial Out: serial Err: serial Net: ZYNQ GEM: ff0e0000, phyaddr ffffffff, interface rgmii-id eth0: ethernet@ff0e0000 Hit any key to stop autoboot: 0 boot Petalinux syntax error Device: sdhci@ff160000 Manufacturer ID: 13 OEM: 14e Name: Q2J55 Tran Speed: 25000000 Rd Block Len: 512 MMC version 5.0 High Capacity: Yes Capacity: 7.1 GiB Bus Width: 8-bit Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 7.1 GiB WRREL Boot Capacity: 16 MiB ENH RPMB Capacity: 4 MiB ENH reading image.ub 21894632 bytes read in 1587 ms (13.2 MiB/s) ## Loading kernel from FIT Image at 10000000 ... Using 'conf@1' configuration Trying 'kernel@1' kernel subimage Description: PetaLinux Kernel Type: Kernel Image Compression: gzip compressed Data Start: 0x100000f4 Data Size: 21865799 Bytes = 20.9 MiB Architecture: AArch64 OS: Linux Load Address: 0x00080000 Entry Point: 0x00080000 Hash algo: crc32 Hash value: ab1f813f Verifying Hash Integrity ... crc32+ OK ## Loading fdt from FIT Image at 10000000 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x114da724 Data Size: 27524 Bytes = 26.9 KiB Architecture: AArch64 Hash algo: crc32 Hash value: 15a0a06b Verifying Hash Integrity ... crc32+ OK Booting using the fdt blob at 0x114da724 Uncompressing Kernel Image ... OK Loading Device Tree to 0000000007ff6000, end 0000000007fffb83 ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.4.0 (email@example.com) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #2 SMP Wed Nov 30 22:39:02 MST 2016 TRUNCATED LINUX STARTUP ********************************************************************* *** *** *** Avnet UltraZed Out Of Box PetaLinux Build V1.0 *** *** *** *** Based Upon the UZ3EG 2016.2 PetaLinux BSP from Avnet *** *** *** *** More information available on UltraZed.org community site *** *** *** *********************************************************************
I'd appreciate any insights
06-15-2017 06:15 AM
06-14-2017 10:48 AM
The boot source is determined by hardware pins, not software. Check with your board designer, they should have either a jumper, DIP switch, or some mechanism for selecting the boot source.
As a temporarily software solution, you can halt uboot and tell it to continue booting by another means. However this will still use the FSBL, u-boot and potentially the bitfile from you vendor. You can switch to your own kernel, devicetree and rootfs this way. But to fully swich, you have to change the hardware pins that select the boot source.
06-15-2017 02:17 AM
I can select the boot source with switches connected to the pins (SW2 Table 2-4 SD). It definitely uses the SD card.
I paused the autoboot and tried bootm, this gives me the following.
Wrong Image Format for bootm command ERROR: can't get kernel image!
According to UG1144 Table 1-9 (pg 33) this is a common error and may be fixed by changing the environment variable bootcmd, which didn't work. So, I followed the other fix, basically start again. Both it and Configuring SD Card ext filesystem Boot (pg 48) complete fine. This time, when I run and pause the bootloader, the bootcmd variable is set correctly to "run sdboot", but on using bootm I get the above output.
I think the problem must be how I'm packaging everything together and where. I put BOOT.BIN (containing the FSBL, PMU firmware, FPGA bitstream and u-boot) and image.ub (the kernel) in the boot partition on the card. I also put the rootfs.ext4 or rootfs.cpio in the rootfs partition.
As I understand it, BOOT.BIN is loaded which starts at the FSBL. This sets the FPGA and PMU. Then u-boot takes over and brings up hardware and starts the kernel. What I don't get is where u-boot gets the kernel's location from (and why it isn't finding the supplied one). I presume petalinux configures it to look on the the SD card for a image.ub, but, in my case, as it doesn't find one it looks elsewhere, finds the stock one somewhere in flash and boots it.
The boot output is now the following when I stop autoboot.
Xilinx Zynq MP First Stage Boot Loader Release 2017.1 Jun 14 2017 - 11:42:44 NOTICE: ATF running on XCZU3EG/silicon v2/RTL5.1 at 0xfffea000, with PMU firmware NOTICE: BL31: Secure code at 0x0 NOTICE: BL31: Non secure code at 0x8000000 NOTICE: BL31: v1.3(release):7d1a673 NOTICE: BL31: Built : 10:30:42, Jun 14 2017 U-Boot 2017.01 (Jun 15 2017 - 09:04:29 +0100) Xilinx ZynqMP ZCU102 revB I2C: Error, wrong i2c adapter 0 max 0 possible Error, wrong i2c adapter 0 max 0 possible ready DRAM: 2 GiB EL Level: EL2 Chip ID: xczu3eg MMC: sdhci@ff160000: 0 (eMMC), sdhci@ff170000: 1 (SD) SF: Detected n25q256a with page size 512 Bytes, erase size 128 KiB, total 64 MiB Error, wrong i2c adapter 0 max 0 possible Error, wrong i2c adapter 0 max 0 possible In: serial Out: serial Err: serial Net: ZYNQ GEM: ff0e0000, phyaddr ffffffff, interface rgmii-id eth0: ethernet@ff0e0000 U-BOOT for board_14_6_project_new ethernet@ff0e0000 Waiting for PHY auto negotiation to complete....... done BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded Hit any key to stop autoboot: 0 ZynqMP> bootm Wrong Image Format for bootm command ERROR: can't get kernel image!
06-15-2017 06:15 AM
06-15-2017 08:04 AM
I believe you may be on to it. Loading the files manually and then trying to boot seems to get closer (additionally I simplified my approach, now only using a single partition).
My issue now is the formatting of the ramdisk, I've tried both cpio and ext4 (build by current config), but corrupt or invalid is reported as follows.
Hit any key to stop autoboot: 0 ZynqMP> fatls mmc 1 13273620 image.ub 5228435 rootfs.ext4.gz 5160179 rootfs.cpio.gz 557664 u-boot.elf 491336 u-boot.bin 6323912 boot.bin 35578 system.dtb .trash-1000/ 7 file(s), 1 dir(s) ZynqMP> fatload mmc 1 0x3000000 image.ub reading image.ub 13273620 bytes read in 896 ms (14.1 MiB/s) ZynqMP> fatload mmc 1 0x3A000000 system.dtb reading system.dtb 35578 bytes read in 16 ms (2.1 MiB/s) ZynqMP> fatload mmc 1 0x20000000 rootfs.cpio.gz reading rootfs.cpio.gz 5160179 bytes read in 359 ms (13.7 MiB/s) ZynqMP> bootm 0x3000000 0x2000000 0x3a00000 ## Loading kernel from FIT Image at 03000000 ... Using 'conf@2' configuration Trying 'kernel@0' kernel subimage Description: Linux Kernel Type: Kernel Image Compression: uncompressed Data Start: 0x030000d8 Data Size: 13236736 Bytes = 12.6 MiB Architecture: AArch64 OS: Linux Load Address: 0x00080000 Entry Point: 0x00080000 Hash algo: sha1 Hash value: 9141c035afa10c7aaca510425b613a423aaba0df Verifying Hash Integrity ... sha1+ OK Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid
Any ideas on which format I should be using, I understood cpio to be standard?
06-15-2017 08:17 AM
06-16-2017 02:22 AM
Thanks for all the help.
For the record, I needed to set the rootfs type to INITRD, not sure why INITRAMFS or SD didn't work, an issue for another day.
I've marked the the answer about manual loading as the solution, as it was most of the solution for me. I only need to load the image.ub and then boot it, to get it working. I'll update with why autoboot wasn't selecting the SD card, when (if) I figure it out.
10-08-2017 01:43 AM
The file image.ub contains the dtb and the file system as such you can just use u-boot to load in the image.ub and then run the bootm command with the address you loaded it to.
11-22-2017 06:02 AM
I have the same problem, also using the UltraZed. I managed to stop the boot process and boot manually from SD card, just as you did, but I don't see this as a long-term solution. Did you manage to figure out how to make it boot from the SD card automatically?
11-22-2017 06:15 AM
I did fix it (not necessarily repeatably), haven't worked on it too much lately though.
After initially trying to fix it, I went on to doing other things with the kernel. Eventually when I came back to it, I completely rebuilt it for unrelated reasons and it worked. In between it working and not working, a few things had changed (different version of the HDF, options in other parts of the kernel, OpenAMP, QT etc. and possibly things I forgot about).
My fix was the following according to my own documentation:
--To boot from SD card go into Subsystem AUTO Hardware Settings → Advanced bootable images storage Settings → boot image settings and select SD, kernel image settings → image storage media → SD, dtd image settings → from SD
--Prepare the SD card
Extract rootfs.cpio to the second partition
--Put the SD card in, set the boot mode switches (SW6) to 1:1 2:0 3:0 4:0 (according to ug1182 pg 19)
Probably nothing you haven't tried
11-22-2017 06:43 AM