Boot Linux from SD boots flash instead

[tayloral]

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 (training@localhost.localdomain) (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 

[rfs613]

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.

[tayloral]

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!

[rfs613 · Accepted solution]

Based on the boot messages, the problem seems to be that the kernel is not being loaded into memory prior to "bootm". Normally this would be done by "bootcmd" which calls "sdboot". I would suggest checking the sdboot and running each of its commands manually.

For example on my zynq (this is considerably older than yours, it uses a zImage for the kernel), just for comparisons, I have in sdboot:

fatload mmc 0 0x3000000 ${kernel_image}
fatload mmc 0 0x2A00000 ${devicetree_image}
fatload mmc 0 0x2000000 ${ramdisk_image}
bootm 0x3000000 0x2000000 0x2A00000

During boot, each of the "fatload" commands will print out the number of bytes it has transferred. I do not see this in your boot log, so I suspect it isn't being called on your system.

I also notice that you have two SD devices, an eMMC (#0) and a SD card (#1). So the "faltload" commands likely need to read "fatload mmc 1 ..." on your system. This is how files are loaded off the SD card and put into RAM.

Your bootloader does seem to be trying to network boot (BOOTP) which is a bit strange, if you have set it for running "sdboot".

Lastly, once you are able to load the kernel and devicetree into memory, then bootm should at least produce some output from Linux kernel. However you will still have to tackle the root filesystem. Normally a small initramfs would be used, as opposed to a rootfs.ext2.

If you want a full filesystem, then rather than loading it as a ramdisk, the normal method would be to partition the SD card, so that the first partition is a FAT filesystem containing BOOT.BIN, you kernel and devicetree, etc. Then the second partition would be formatted as ext2 (or other) filesystem, and linux would be told to use it with a kernel commandline of root=/dev/sdb2 for example (assuming sda is your eMMC, then sdb would be your SD card) and the 2 is the second partition.

[tayloral]

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?

[rfs613]

Good, that looks like progress.

For the ramdisk, yes a cpio archive is often used (in the form of an initramfs). In case you are making the archive yourself, be sure that you use "cpio -H newc" (or the equivalent "-c" flag) to use the correct format.

I think there may be a further complication from the newer "FIT image", your image.ub seems like it is using this. I haven't delved into that myself, but I think it wrappers the zImage, devicetree, and ramdisk into one. As opposed to treating them all as separate pieces as was done in the past. So it would seem that your image.ub thinks it should have a ramdisk, but it either is missing or not in the correct format. (Further evidence for this: your image.ub is over 12MB, so it surely contains more than a linux kernel).

In other words: I don't think it is currently using the rootfs.cpio.gz that you are loading, rather it's looking within the image.ub file.

You could either try using a zImage kernel, eg. doing it the old way with separate pieces. Or you could investigate how your image.ub is being put together.

[tayloral]

It lives!

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.

[taylo_ap]

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. 

[jeffrey.johnson]

@tayloral

Hi,

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?

Thanks.

Jeff

[tayloral]

 Hi,

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

1. open Gparted as root, select the SD card
2. Delete any partitions already present and write that
3. Leave 4MiB unoccupied at the start then a fat32 partition for the boot (at least 40 MiB to fit all files) and another partition for storage ext4 called rootfs.  Set the boot flag on the boot partition.
4. Copy image.ub, devicetree.dtb and BOOT.BIN to the boot partition

5. 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

[jeffrey.johnson]

@tayloral

OK so it turns out to be a known issue, here is the work around: https://www.xilinx.com/support/answers/69780.html

That fixed it for me.

Jeff