cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
peta_n00b
Visitor
Visitor
946 Views
Registered: ‎10-09-2020

Unable to boot after packaging image.ub into single BOOT.BIN on Zynq UltraScale+

Jump to solution

We have a Petalinux 2020.1 project that successfully boots from an FAT32 formatted SD card on the Zynq ZCU102 with UltraScale+. Currently we're combining the linux kernel and root file system into the single image.ub using the INITRD configuration for the rootfile system to keep our everything together and simplify image updates. Currently we are able to boot without issue by putting the image.ub, BOOT.BIN with PL datastream file and the boot.scr file.

I wish to package the image.ub into the BOOT.BIN file as well. I tried following the suggestions on this document to package everything using petalinux-package. My petalinux-package call looks like this right now:

petalinux-package --boot --fsbl --u-boot --pmufw --fpga /path/to/wb_zcu102.bit --kernel --force

I see petalinux-package finding the image.ub in the images/linux/ directory.

When I try putting just the new BOOT.BIN and boot.scr on the SD card and booting, I get to the boot loader, but my output is:

U-Boot 2020.01 (May 19 2021 - 21:36:23 +0000)

Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP
DRAM:  4 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu9eg
NAND:  0 MiB
MMC:   mmc@ff170000: 0
In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Bootmode: LVL_SHFT_SD_MODE1
Reset reason:   EXTERNAL
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id

Warning: ethernet@ff0e0000 using MAC address from DT
eth0: ethernet@ff0e0000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2007 bytes read in 16 ms (122.1 KiB/s)
## Executing script at 20000000
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
## Executing script at 20000000
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2007 bytes read in 16 ms (122.1 KiB/s)
## Executing script at 20000000
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
MMC Device 1 not found
no mmc device at slot 1
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
device 0 offset 0x3e80000, size 0x80000
SF: 524288 bytes @ 0x3e80000 Read: OK
## Executing script at 20000000
Wrong image format for "source" command
SCRIPT FAILED: continuing...

It then continues to search for various peripherals and never ends up booting the linux OS.

I then on a whim tried putting the image.ub from the build on the SD card with the same BOOT.BIN and boot.scr and the system and linux booted successfully.

U-Boot 2020.01 (May 19 2021 - 21:36:23 +0000)

Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP
DRAM:  4 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu9eg
NAND:  0 MiB
MMC:   mmc@ff170000: 0
In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Bootmode: LVL_SHFT_SD_MODE1
Reset reason:   EXTERNAL
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id

Warning: ethernet@ff0e0000 using MAC address from DT
eth0: ethernet@ff0e0000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2007 bytes read in 15 ms (129.9 KiB/s)
## Executing script at 20000000
80192160 bytes read in 5240 ms (14.6 MiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x100000f8
     Data Size:    8088355 Bytes = 7.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x00080000
     Entry Point:  0x00080000
     Hash algo:    sha256
     Hash value:   215aacb3219c9ed1940746f2a0636c05acc3867663715f2c015f3286f6a8ce19
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  petalinux-image-minimal
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x107c535c
     Data Size:    72042954 Bytes = 68.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   76894f69f1b53f9bb9e17a418f4ef13b84493425afc456dae7d8d6997403d07e
   Verifying Hash Integrity ... sha256+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'fdt@system-top.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x107b6d2c
     Data Size:    58717 Bytes = 57.3 KiB
     Architecture: AArch64
     Hash algo:    sha256
     Hash value:   747d1cf0e9f908813d6308d8b80ec08a6e4599b79d9961060c44897f00f85b89
   Verifying Hash Integrity ... sha256+ OK
   Booting using the fdt blob at 0x107b6d2c
   Uncompressing Kernel Image
   Loading Ramdisk to 74b4b000, end 78fff9ca ... OK
   Loading Device Tree to 000000000ffee000, end 000000000ffff55c ... OK

Starting kernel ...

Naturally this defeats the purpose of me packaging the image.ub into the BOOT.BIN. Is there some configuration or setting I may be missing? I've seen some examples of bundling use bootgen and a BIF file, but I'm unsure on what my BIF would look like.

Any help would be appreciated.

0 Kudos
1 Solution

Accepted Solutions
stephenm
Xilinx Employee
Xilinx Employee
820 Views
Registered: ‎09-12-2007

Yes, you are correct. It will do a fatload from the mmc. You dont want to do this, as it is already loaded into memory. So, you would need to update the boot.scr

you can use dumpimage to do this:

u-boot-xlnx/tools/dumpimage -T script boot.scr -o boot.txt

Then make your changes:

boot_txt.PNG 

Then package it back up again:

mkimage -c none -A arm -T script -d boot.txt boot.scr

View solution in original post

0 Kudos
16 Replies
peta_n00b
Visitor
Visitor
938 Views
Registered: ‎10-09-2020

I have a feeling the issue is the boot.scr script that is generated with the petalinux build is part of the problem since it attempts to load the image.ub file. It makes sense that if the file was not present it would fail to boot. But I do not know how to modify the script to use the image.ub in the BOOT.BIN instead. The mmc portion of the boot.scr is below:

if test "${boot_target}" = "mmc0" || test "${boot_target}" = "mmc1" ; then
	if test -e ${devtype} ${devnum}:${distro_bootpart} /image.ub; then
		fatload ${devtype} ${devnum}:${distro_bootpart} 0x10000000 image.ub;
		bootm 0x10000000;
		exit;
         fi
	 if test -e ${devtype} ${devnum}:${distro_bootpart} /Image; then
		fatload ${devtype} ${devnum}:${distro_bootpart} 0x00200000 Image;;
	fi
	if test -e ${devtype} ${devnum}:${distro_bootpart} /system.dtb; then
		fatload ${devtype} ${devnum}:${distro_bootpart} 0x00100000 system.dtb;
	fi
	if test -e ${devtype} ${devnum}:${distro_bootpart} /rootfs.cpio.gz.u-boot; then
		fatload ${devtype} ${devnum}:${distro_bootpart} 0x04000000 rootfs.cpio.gz.u-boot;
		booti 0x00200000 0x04000000 0x00100000
		exit;
	fi
	booti 0x00200000 - 0x00100000
	exit;
fi
0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
882 Views
Registered: ‎09-12-2007

Yes, i suspect the boot.scr too. Can you share the bif file that is generated when you run the petalinux-package? This will be in the build folder. should be called bootgen.bif

 

 

0 Kudos
peta_n00b
Visitor
Visitor
857 Views
Registered: ‎10-09-2020

Hey @stephenm, thanks so much for the prompt reply.

Here's what the bootgen.bif looks like:

the_ROM_image:
{
[bootloader, destination_cpu=a53-0] /home/tmp/tmp.D6iO9mibWC/zynqmp_fsbl.elf
[pmufw_image] /home/tmp/tmp.D6iO9mibWC/pmufw.elf
[destination_device=pl] /home/tmp/tmp.D6iO9mibWC/wb_zcu102.bit
[destination_cpu=a53-0, exception_level=el-3, trustzone] /home/tmp/tmp.D6iO9mibWC/bl31.elf
[destination_cpu=a53-0, load=0x00100000] /home/tmp/tmp.D6iO9mibWC/system.dtb
[destination_cpu=a53-0, exception_level=el-2] /home/tmp/tmp.D6iO9mibWC/u-boot.elf
[destination_cpu=a53-0, partition_owner=uboot] /home/tmp/tmp.D6iO9mibWC/image.ub
}

Interestingly, it refers to a directory in the tmp/ directory that doesn't exist on my system. Shouldn't it use the images in my images/linux/ directory?

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
840 Views
Registered: ‎09-12-2007

Petalinux uses a tmp directory. It then copies the images from this tmp directory to the petalinux project.

Can you set the load address to 0x10000000 for the image.ub. This is the address expected by in the boot.scr:

petalinux-package --boot --fsbl --u-boot --pmufw --fpga /path/to/wb_zcu102.bit --kernel --load 0x10000000 --force

boot.PNG

0 Kudos
peta_n00b
Visitor
Visitor
827 Views
Registered: ‎10-09-2020

Good suggestion, but unfortunately I'm seeing the same behavior. If I add in the image.ub on the SD card it still boots normally. Without it I get the same:

Found U-Boot script /boot.scr
2007 bytes read in 16 ms (122.1 KiB/s)
## Executing script at 20000000
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...

error. I do see in the new bootgen.bif that the image.ub's load address is updated:


the_ROM_image:
{
[bootloader, destination_cpu=a53-0] /home/tmp/tmp.A9hgT5Ei76/zynqmp_fsbl.elf
[pmufw_image] /home/tmp/tmp.A9hgT5Ei76/pmufw.elf
[destination_device=pl] /home/tmp/tmp.A9hgT5Ei76/wb_zcu102.bit
[destination_cpu=a53-0, exception_level=el-3, trustzone] /home/tmp/tmp.A9hgT5Ei76/bl31.elf
[destination_cpu=a53-0, load=0x00100000] /home/tmp/tmp.A9hgT5Ei76/system.dtb
[destination_cpu=a53-0, exception_level=el-2] /home/tmp/tmp.A9hgT5Ei76/u-boot.elf
[destination_cpu=a53-0, partition_owner=uboot, load=0x10000000] /home/tmp/tmp.A9hgT5Ei76/image.ub
}

Was wondering if there needs to be a change to the boot.scr since it uses 'fatload' to search for a file called image.ub. Or does the '${devtype} ${devnum}:${distro_bootpart} refer here to the BOOT.BIN file's offset at 0x10000000? Perhaps those variables are not being set?

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
821 Views
Registered: ‎09-12-2007

Yes, you are correct. It will do a fatload from the mmc. You dont want to do this, as it is already loaded into memory. So, you would need to update the boot.scr

you can use dumpimage to do this:

u-boot-xlnx/tools/dumpimage -T script boot.scr -o boot.txt

Then make your changes:

boot_txt.PNG 

Then package it back up again:

mkimage -c none -A arm -T script -d boot.txt boot.scr

View solution in original post

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
754 Views
Registered: ‎09-12-2007

I tried this on my end and it works for me. However, I needed to update the BIF to make the partition owner the fsbl and not the uboot:

the_ROM_image:
{
	[bootloader, destination_cpu=a53-0] zynqmp_fsbl.elf
	[pmufw_image] pmufw.elf 
	[destination_cpu=a53-0, exception_level=el-3, trustzone] bl31.elf
	[destination_cpu=a53-0, load=0x00100000] system.dtb
	[destination_cpu=a53-0, exception_level=el-2] u-boot.elf
	[destination_cpu=a53-0, partition_owner=fsbl, load=0x10000000] image.ub
}
0 Kudos
peta_n00b
Visitor
Visitor
731 Views
Registered: ‎10-09-2020

So I must be doing something wrong on my end. Using the dumpimage and mkimage executables found in the build directory I modified the boot.scr as you suggested:

if test "${boot_target}" = "mmc0" || test "${boot_target}" = "mmc1" ; then
    bootm 0x10000000;
    exit;
fi

I then tried copying the old bootgen.bif and modifying it as you suggested:

the_ROM_image:
{
        [bootloader, destination_cpu=a53-0] zynqmp_fsbl.elf
        [pmufw_image] pmufw.elf
        [destination_device=pl] /path/to/datastream.bit
        [destination_cpu=a53-0, exception_level=el-3, trustzone] bl31.elf
        [destination_cpu=a53-0, load=0x00100000] system.dtb
        [destination_cpu=a53-0, exception_level=el-2] u-boot.elf
        [destination_cpu=a53-0, partition_owner=fsbl, load=0x10000000] image.ub
}

I then tried packaging via petalinux-package --boot --format BIN --bif new_bootgen.bif --force. I was not able to boot the board at all. No UART output for u-boot and the INIT_DONE LED was red. I tried using the other format petalinux-package --boot --fsbl --u-boot --pmufw --fpga /path/to/wb_zcu102.bit --kernel --load 0x10000000 --force from earlier and got the same result.

Should I not have used those executables from the build directory? Can I download them from Xilinx somewhere else? To make sure it isn't a hardware issue I replaced the SD card files with a previous known good image and was able to boot without issue.

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
717 Views
Registered: ‎09-12-2007

Does it boot if the partition_owner is uboot?

We are loading the image.ub via the fsbl. So it could be hanging here.

Can you enable the debug in the fsbl to see how it is performing?

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
702 Views
Registered: ‎09-12-2007

The steps to add debug to fsbl in Petalinux is shown here

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips

0 Kudos
bnewlin
Contributor
Contributor
675 Views
Registered: ‎03-10-2015

Looks like we've been struggling with this same problem in parallel, albeit I'm using Petalinux 2018.1 and Zynq which will have some differences.  Take a look at the solution that worked for me.  With any luck, you can glean something useful from it.

0 Kudos
peta_n00b
Visitor
Visitor
656 Views
Registered: ‎10-09-2020

Interestingly doing a full rebuild seems to have fixed the booting issue. Here's the FSBL output:

 

Xilinx Zynq MP First Stage Boot Loader
Release 2020.1   May 21 2021  -  19:00:07
Reset Mode      :       System Reset
Platform: Silicon (3.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU9EG
FMC VADJ Configuration Successful
Board Configuration successful
Processor Initialization Done
================= In Stage 2 ============
SD1 with level shifter Boot Mode
SD: rc= 0
File name is BOOT.BIN
Multiboot Reg : 0x0
Image Header Table Offset 0x8C0
*****Image Header Table Details********
Boot Gen Ver: 0x1020000
No of Partitions: 0x6
Partition Header Address: 0x440
Partition Present Device: 0x0
Initialization Success
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x440379
Data word offset: 0x440379
Total Data word length: 0x440379
Destination Load Address: 0xFFFFFFFF
Execution Address: 0x0
Data word offset: 0x11540
Partition Attributes: 0x26
Destination Device is PL, changing LoadAddress
Non authenticated Bitstream download to start now
DMA transfer done
PL Configuration done successfully
Partition 1 Load Success
======= In Stage 3, Partition No:2 =======
UnEncrypted data Length: 0x31EC
Data word offset: 0x31EC
Total Data word length: 0x31EC
Destination Load Address: 0xFFFEA000
Execution Address: 0xFFFEA000
Data word offset: 0x4518C0
Partition Attributes: 0x117
Partition 2 Load Success
======= In Stage 3, Partition No:3 =======
UnEncrypted data Length: 0x3958
Data word offset: 0x3958
Total Data word length: 0x3958
Destination Load Address: 0x100000
Execution Address: 0x0
Data word offset: 0x454AB0
Partition Attributes: 0x116
Partition 3 Load Success
======= In Stage 3, Partition No:4 =======
UnEncrypted data Length: 0x38620
Data word offset: 0x38620
Total Data word length: 0x38620
Destination Load Address: 0x8000000
Execution Address: 0x8000000
Data word offset: 0x458410
Partition Attributes: 0x114
Partition 4 Load Success
======= In Stage 3, Partition No:5 =======
UnEncrypted data Length: 0x131E3BB
Data word offset: 0x131E3BB
Total Data word length: 0x131E3BB
Destination Load Address: 0x10000000
Execution Address: 0x0
Data word offset: 0x490A30
Partition Attributes: 0x116
Partition 5 Load Success
All Partitions Loaded
================= In Stage 4 ============
Protection configuration applied
  ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000
NOTICE:  BL31: v2.2(release):v1.1-5588-g5918e656e
NOTICE:  BL31: Built : 18:57:45, May 21 2021

 

and here's the output of the u-boot. Looks like its failing to read the script:

 

U-Boot 2020.01 (May 21 2021 - 19:02:21 +0000)

Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP
DRAM:  4 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu9eg
NAND:  0 MiB
MMC:   mmc@ff170000: 0
In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Bootmode: LVL_SHFT_SD_MODE1
Reset reason:   EXTERNAL
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id

Warning: ethernet@ff0e0000 using MAC address from DT
eth0: ethernet@ff0e0000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2061 bytes read in 15 ms (133.8 KiB/s)
## Executing script at 20000000
SCRIPT FAILED: continuing...
## Executing script at 20000000
SCRIPT FAILED: continuing...
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2061 bytes read in 16 ms (125 KiB/s)
## Executing script at 20000000
SCRIPT FAILED: continuing...
MMC Device 1 not found

 

Something is still wrong with the boot.scr file I think. It can find it since the size is correct, but I can't tell why it fails.

I will look into @bnewlin's suggestion when Im able. Thanks for the suggestion.

I worry that using the dumpfile and mkimage executable files within the petalinux build directory is not ideal. Is there somewhere I can find download those tools?

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
649 Views
Registered: ‎09-12-2007

You can use bootm 0x10000000 on the uboot console. 

 

If this works, then you know that the image.ub is loaded correctly

 

Also, can you try with my boot.scr I added above

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
641 Views
Registered: ‎09-12-2007

Also, the changes made to the boot.scr assumes you are booting from SD card. Is this true on your end?

0 Kudos
peta_n00b
Visitor
Visitor
574 Views
Registered: ‎10-09-2020

Yes I am booting from a SD card. I tried your boot.scr and was able to boot successfully. Great!

The question then is what is wrong with by boot.scr. Like I said previously, I used the dumpimage and mkimage executables that are brought into the petalinux build directory. That doesn't seem ideal to me. From this page, I see two links to dumpimage and mkimage saying they can be installed or I can use the ones generated by the petalinux build.

As a last test I took your boot.scr, copied its contents to a text file, used mkimage to create a new boot.scr and sure enough that booted successfully.

It looks like my boot.scr which was modified from the petalinux-generated one was the culprit. Not 100% sure why but your script and the BIF configuration did solve this issue.

Thanks so much for taking the time to help out. I wouldn't mind learning a bit more about the boot.scr if you know of any good resources.

Thanks again!

 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
492 Views
Registered: ‎09-12-2007

The dumpimage is useful. You can extract the image.ub too. I do this for the rootfs if I want to change this without calling Petalinux.

I did notice that when I dumped the scr that it added a few bytes to the start that I removed. So, could be this?

Try dumping my boot.scr, and you non working scr and compare in an text editor. You should see the diff.

Also, if modifying on Windows. It's always good to do a dos2unix on the file

 

0 Kudos