SD card does not boot in ZCU104

[maju42]

Hi,

I am trying to boot my ZCU104 board from an SD card. I followed the instructions: on Page 38 of the Petalinux tools documentation(https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1144-petalinux-tools-reference-guide.pdf). I copied the BOOT.bin and the image.ub files from mypetalinux-project/images/linux to the SD card directly which is partitioned fully as FAT32 and labeled BOOT. On connecting the FPGA with my PC nothing shows up in the serial console and the LED stays red.

So, I downloaded the prebuilt images for ZCU104 from here (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/57639129/Zynq+2018.3+Release) and loaded their files on the SD card, it boots normally. The LED is green and I am able to see the boot messages on the console. 

I am not sure why when I load my BOOT.bin and image.ub from the petalinux project the console stays blank. I followed the following steps to build my project:

petalinux-config --get-hw-description=/path/system.hdf
[Change machine name to zcu104-reva and changed Root file system -> SD card]

petalinux-config -c kernel
[General setup -> cancel Initial RAM filesystem and RAM disk support]

petalinux-config -c rootfs
[Filesystem Packages–> misc, select packagegroup-core-buildessential->include all the packages]

petalinux-build
[Project builds successfully at this stage]

goto mypetalinux-project->images->linux
Execute the following command:
petalinux-package --boot --fsbl zynqmp.fsbl --fpga system.bit --pmufw pmufw.elf --u-boot

After this, I copy the generated BOOT.bin and the image.ub files to the SD card. But when I set the board to boot mode and connect to my PC nothing comes up in the console. If anyone can suggest what I am doing wrong here that will be of utmost help. Thanks!

[rwillis]

@maju42 

You don't have to compile the FSBL in the SDK you can do that in Petalinux.

I marked my previous port as resolved and added my workflow for patching and compiling the FSBL in Petalinux 2018.2 it would be the same for 2019.1

ref. https://forums.xilinx.com/t5/Embedded-Linux/ZCU102-Failure-in-getting-an-SDCard-to-boot-Vivado-amp-Petalinux/m-p/1030215#M37172

You should not have to worry about the FSBL in 2019.1 though... it should have been patched... you can use the above technique to add in debugging to the FSBL though. That may help you to trace down the issue.

 - Richard

[maju42]

Hi @rwillis , as you mentioned in this thread: https://forums.xilinx.com/t5/Embedded-Linux/ZCU102-Failure-in-getting-an-SDCard-to-boot-Vivado-amp-Petalinux/m-p/1030215#M37172

"

The new evidence points to an issue still within the FSBL. Somehow when the project BSP is changed from the default to the Vivado .hdf, using the command: petalinux-config --get-hw-description=<path/to/hdf-file/directory>
,the FSBL is affected to the extent that not even boot text appears in the serial console. I have to assume the SDCard is booting as no changes were made to the partitions only the 2 files in the fat32 partition were (fully!) deleted and replaced.

 - there are binary differences between the zynqmp_fsbl.elf files, generated in the default project and in our custom bsp. The default projects's FSBL builds to a size of 131032 bytes and the one built in our custom bsp project builds to 126936 bytes.

(!) When I use the default project's FSBL instead of the one built in the custom BSP project, the board boots with our FPGA and our AXI interfaces are intact (we have an issue using i2c-tools with the u20 external clock however, attempts to modify registers return with "device is busy")

...

So why is our project's FSBL different from the one built in the default project? 

(default project is created by using: petalinux-create -t project -s <path/to/bsp>, where the BSP used is: xilinx-zcu102-v2018.3-final.bsp)
(our project modifies the above initial project by using petalinux-config --get-hw-description, as already mentioned above)

"

The exact same thing is happening to me. If this is the case, is it okay to use the '.elf' files from the official distro in my custom petalinux project to package it? But of course, the <fpga bit file> will be from my custom project. The only changed files will be the '.elf' files.

@tejaallani @watari EDIT: If I do the above, I get the following boot message and it stops booting after this:

[    5.512786] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
[    5.521207] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.19.0-xilinx-v2019.1 #1
[    5.528417] Hardware name: ZynqMP ZCU104 RevC (DT)
[    5.533191] Call trace:
[    5.535630]  dump_backtrace+0x0/0x148
[    5.539278]  show_stack+0x14/0x20
[    5.542578]  dump_stack+0x90/0xb4
[    5.545883]  panic+0x120/0x268
[    5.548922]  mount_block_root+0x1b0/0x260
[    5.552913]  mount_root+0x11c/0x148
[    5.556385]  prepare_namespace+0x14c/0x194
[    5.560465]  kernel_init_freeable+0x1b8/0x1d4
[    5.564806]  kernel_init+0x10/0xfc
[    5.568191]  ret_from_fork+0x10/0x18
[    5.571751] SMP: stopping secondary CPUs
[    5.575664] Kernel Offset: disabled
[    5.579135] CPU features: 0x0,20802004
[    5.582866] Memory Limit: none
[    5.585909] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) ]---

I was able to fix that by creating a rootfs partition in my SD card. It successfully booted and I can see the main home screen.

Now the only question that is not clear to me, if it is okay to use the '.elf' files from the official distro in my custom petalinux project to package it keeping the <fpga bit file> will be from my custom project. The only changed files will be the '.elf' files.

---

[rwillis]

So you have a working FSBL now and are on to the Linux part of the boot-up?

Just FYI,

BOOT.BIN contains:
 - FSBL
 - ATF
 - U-BOOT
 - FPGA Image (optional)

U-BOOT opens: image.ub ...

image.ub contains:
 - linux kernal image + compiled in modules
 - device tree image
 - initial ramdisk (initrd) <-- contains modular modules, and libraries and applications (the '/' drive)
 - potentially other filesystem images

The kernel will do a "root pivot" from an initrd to another filesystem, eg. one that is mounted on a ext3 partition on the SD Card (root/) or it will stay with the initrd and use that for the filesystem. The initrd is always running in a RAM filesystem but is packaged onto the SDCard inside of image.ub

As to your boot log it looks like u-boot could not find an initrd and the Linux kernel paniced when it was not given a file system to work against.
u-boot sets up the initrd for the kernel to use before the kernel starts. There was none in the image.ub

You need to have a filesystem (initrd or a mounted partition) for Linux to use otherwise it will get upset.

Configuration of what goes in the image.ub is done when invoking 'petalinux-config' with no other arguments.

 - Richard

[rwillis]

@maju42 

"Now the only question that is not clear to me, if it is okay to use the '.elf' files from the official distro in my custom petalinux project to package it keeping the <fpga bit file> will be from my custom project. The only changed files will be the '.elf' files."

As to this question, it should be OK with the exception of the linux and filesystem images; they would be the ones mostly affected by changes in the FPGA as you may need custom linux drivers to support IP modules in the FPGA PL fabric.

I personally would be bothered by just re-using pre-compiled FSBL etc .elf files as it means that there is still something inherently broken in your build system and/or work flow. I would dig into that and fix it in the long term.

 - Richard

[watari]

Hi @maju42 

How do you generate 2nd partition on /dev/mmmmcblk0 ?

What kind of file system do you generate ? VFAT ? ext3 ? or something ?

It seems partititon issue.

Best regards,

[maju42]

Hi @watari , I create the second partition using gpart as ext4 format. I name this as rootfs. My first BOOT partition is in fat32 format. To copy the files to rootfs I use the following commands:

$ sudo umount /dev/sdX2
$ sudo dd if=rootfs.ext4 of=/dev/sdX2
...
$ sync

[watari]

Hi @maju42 

Would you share the following ?

$ parted /dev/sdX print list

I suspect start sector number is wrong.

Best regards

[rwillis]

@maju42 
In response to @watari  ...

"Hi @watari , I create the second partition using gpart as ext4 format. I name this as rootfs. My first BOOT partition is in fat32 format. To copy the files to rootfs I use the following commands:

$ sudo umount /dev/sdX2
$ sudo dd if=rootfs.ext4 of=/dev/sdX2
...
$ sync

"

FYI - An alternate way of getting the rootfs image onto the second partition is to use cpio.

1) Delete existing files 
cd {/path/to/sdcard/root}
sudo rm -rf *
sudo cpio -i< {/path/to/project}/image/linux/rootfs.cpio

 I use this for zcu102 boards. I am assuming the same option is available on your board... make sure you are in the right directory before running the rm command.

 - Richard

[maju42]

Hi @watari , here is the list:

Model: Generic STORAGE DEVICE (scsi)
Disk /dev/sdb: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  1042MB  1038MB  primary  fat32
 2      1042MB  7543MB  6501MB  primary  ext4
 3      7543MB  15.9GB  8388MB  primary  ext4

Hi @rwillis , Thank you for the info. I'll keep it in mind.

[watari]

Hi @maju42 

Would you change format id from 0x0B (FAT32) to 0x0C (FAT32(LBA)) ?

Best regards,

[maju42]

Hi @rwillis , In my petalinux project, I had to change the system-user.dtsi to override the compatible attribute value and add a reserved memory.  After this, I am building the petalinux project, and as I have mentioned before, I am replacing the elf files from the actual zcu104 distribution to successfully package it and generate the BOOT.BIN file. I hope the change in system-user.dtsi is still retained even after changing the elf files.

(I just want to make sure, since when the fpga boots up, I am loading an additional kernel module in it, to run some tests. But these test fails. I hope it is not because it did not encounter the changes I made in system-user.dtsi)

[yunq · Accepted solution]

I don't know if mine is your solution, but I recently ran into the same issue as yours. FSBL won't show up in the terminal.

The correct solution for me, is to make sure the PS configuration is correct in your block design. I am not sure how you started your petalinux project, but for me, I used some tcl script to generate the block design, and exported that design out to build petalinux project. It turns out the tcl script does not have correct ZCU104 PS configurations. I adjusted that to the correct one, and the image booted successfully.

Good luck.

[maju42]

Hi @yunq , I am generating the .bit file and exporting the hardware design using Vivado

My Zynq Ultrascale IP configuration looks like this:

Now I am not sure what are the correct ZCU104 PS configurations or where to change them. Can you suggest how to run the tcl script with the correct configurations? Many thanks.

EDIT: I found a stupid workaround for this. I downloaded the zcu104-2019.1 bsp files from the xilinx website. This included the hardware design as well. I edited the design and used the zynq IP with the same configuration as it has been used in the bsp in my own project. I imported the hardware design in my petalinux project and the fpga boots successfully from the image files generated.

[yunq]

The zcu104 bsp does contain the correct PS setting. That is what I would do as well.

[nju0441]

Hi @rwillis 

Thanks for your knowledge.

By referring your answer of "2) BOOT.BIN creation", I generate new BOOT.BIN and the led turns to green.

But in console, I found "Kernel panic - not syncing: No working init found." and this stop the kernel loding procedure....

I compare the image.ub from "zcu104 1028.2 release" and image.ub built by myself, I found the size of later one(~8.1M) is 10% of former one(~84M).

I suspect the image.ub lacks of a lot stuff for kernel loading, but I'm a newbie of linux kernel. So can you please help me? How to generate correct image.ub?

Attachement is my boot log "teraterm.bootok.log" and xilinx official boot log "teraterm.good.log". I use sd-card to startup zcu104.