cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
3,204 Views
Registered: ‎04-11-2018

Migrating from PetaLinux 2017.4 to 2018.1 - extra hoops to jump through

I wanted to document my migration from PetaLinux 2017.4 to 2018.1, in case it saves anyone else some time. For background, I have a fully scripted build from Vivado through SDK to PetaLinux, targeting a MicroZed based board (7Z020).

Aside from renaming device-tree-generation_%.bbappend to device-tree.bbappend as mentioned in the Migration appendix in UG1144, I found I was also having trouble with my FSBL not getting generated and U-Boot failing to build.

 

FSBL Changes

 

After updating, I found that my FSBL wasn't being generated as part of petalinux-build. I keep {PL_ROOT}/project-spec/meta-user/conf/petalinuxbsp.conf in source control. In 2017.4, this was essentially a blank file by default. In 2018.1, this now includes the following:

#User Configuration

#OE_TERMINAL = "tmux"

# Add EXTRA_IMAGEDEPENDS default components
EXTRA_IMAGEDEPENDS_append_zynqmp = " virtual/fsbl virtual/pmu-firmware arm-trusted-firmware"
EXTRA_IMAGEDEPENDS_append_zynq = " virtual/fsbl"
EXTRA_IMAGEDEPENDS_append_microblaze = " virtual/fsboot virtual/elfrealloc"


#Remove all qemu contents
IMAGE_CLASSES_remove = "image-types-xilinx-qemu qemuboot-xilinx"
IMAGE_FSTYPES_remove = "wic.qemu-sd"

EXTRA_IMAGEDEPENDS_remove = "qemu-helper-native virtual/boot-bin"

Without the EXTRA_IMAGEDEPENDS_append_*, the FSBL does not get built by default. This change in FSBL generation behavior should be covered in the Migration information.

 

U-Boot Changes

 

U-Boot seems to have undergone a similar change in default behavior. I keep {PL_ROOT}/project-spec/meta-user/recipes-bsp/u-boot/* under source control. In 2017.4, the default platform-top.h was: 

#include <configs/platform-auto.h>
#define CONFIG_SYS_BOOTM_LEN 0xF000000

/*Required for uartless designs */
#ifndef CONFIG_BAUDRATE
#define CONFIG_BAUDRATE 115200
#ifdef CONFIG_DEBUG_UART
#undef CONFIG_DEBUG_UART
#endif
#endif

With this config, u-boot fails to build during petalinux-build. The new default platform-top.h in 2018.1 is:

#include <configs/platform-auto.h>
#define CONFIG_SYS_BOOTM_LEN 0xF000000
#define DFU_ALT_INFO_RAM \
                "dfu_ram_info=" \
        "setenv dfu_alt_info " \
        "image.ub ram $netstart 0x1e00000\0" \
        "dfu_ram=run dfu_ram_info && dfu 0 ram 0\0" \
        "thor_ram=run dfu_ram_info && thordown 0 ram 0\0"

#define DFU_ALT_INFO_MMC \
        "dfu_mmc_info=" \
        "set dfu_alt_info " \
        "${kernel_image} fat 0 1\\\\;" \
        "dfu_mmc=run dfu_mmc_info && dfu 0 mmc 0\0" \
        "thor_mmc=run dfu_mmc_info && thordown 0 mmc 0\0"


/*Required for uartless designs */
#ifndef CONFIG_BAUDRATE
#define CONFIG_BAUDRATE 115200
#ifdef CONFIG_DEBUG_UART
#undef CONFIG_DEBUG_UART
#endif
#endif

/*Define CONFIG_ZYNQ_EEPROM here and its necessaries in u-boot menuconfig if you had EEPROM memory. */
#ifdef CONFIG_ZYNQ_EEPROM
#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN         1
#define CONFIG_SYS_I2C_EEPROM_ADDR             0x54
#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS      4
#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
#define CONFIG_SYS_EEPROM_SIZE                 1024 /* Bytes */
#define CONFIG_SYS_I2C_MUX_ADDR                0x74
#define CONFIG_SYS_I2C_MUX_EEPROM_SEL          0x4
#endif

Again, this change isn't mentioned in the Migration index.

 

U-Boot Bug?

 

Upon building my project and trying to boot from an SD card, U-Boot was failing with the error Unknown command 'booti' - try 'help'. I'm a U-Boot novice, but after a LOT of comparing changes, merging my 2017.4 configs with the 2018.1 defaults (and general shotgun debugging), it seems there may be a bug with setting U-Boot to load the DTB from an SD card.

 

In {PL_ROOT}/project-spec/configs/config, the default dtb image setting:

CONFIG_SUBSYSTEM_IMAGES_ADVANCED_AUTOCONFIG_DTB_MEDIA_BOOTIMAGE_SELECT=y

produces a U-Boot default boot command of:

default_bootcmd=run uenvboot; run cp_kernel2ram && bootm ${netstart}

Instead, if the dtb image setting is configured to load from an SD card:

CONFIG_SUBSYSTEM_IMAGES_ADVANCED_AUTOCONFIG_DTB_MEDIA_SD_SELECT=y

then the default boot command changes to:

default_bootcmd=run uenvboot; run cp_kernel2ram && run cp_dtb2ram && booti ${netstart} - ${dtbnetstart}

The problem is the bootm becoming booti. As a workaround, I tried redefining default_bootcmd in a uEnv.txt on my SD card. I can see the variable has updated by running printenv in U-Boot, but the original default still seems to get loaded at startup and the booti error appears. Annoyingly, just doing run default_bootcmd after the initial error results in a normal boot using the default defined in uEnv.txt. I'm guessing there is some kind of env loading order problem. If anyone can let me know why uEnv.txt gets ignored, I would be keen to know!

Instead, my current workaround is to redefine CONFIG_BOOTCOMMAND in platform-top.h by adding the following to the bottom of the file:

/* Due to a bug where having u-boot load dtb from SD card causes the boot
 * command to default to using booti instead of bootm on Zynq, the defult build
 * fails to boot. This boot command override is a temporary workaround.
*/
#ifdef CONFIG_BOOTCOMMAND
#undef CONFIG_BOOTCOMMAND
#define CONFIG_BOOTCOMMAND	"run uenvboot; run cp_kernel2ram && run cp_dtb2ram && bootm ${netstart} - ${dtbnetstart}"
#endif

Is this behavior a bug, or am I doing something wrong? It worked fine in 2017.4

 

Build Warnings

 

I'm really not a fan of warnings in default builds. It doesn't give confidence that everything is setup right. I get the same warnings (about virtualization and sysvinit-inittab-2.88dsf-r10.plnx_zynq7) on a default zynq build as in this post. I only bring it up again here in case someone else sees them as part of a migration to 2018.1 and is concerned.

 

Any input on anything I am doing wrong, or better workarounds, would be greatly appreciated!

Cheers,

Iain

4 Replies
Highlighted
2,744 Views
Registered: ‎02-07-2008

Re: Migrating from PetaLinux 2017.4 to 2018.1 - extra hoops to jump through

Hi Iain,

 

Just wanted to say thanks for posting this information. I got stuck with the same issues, the BOOT.bin file wasn't being generated, nor was the zynq_fsbl.elf. When I made your changes, specifically the device-tree filename change and the additions to the petalinuxbsp.conf file, the problems were fixed.

 

Thank you.

 

Jeff

 

0 Kudos
Highlighted
Observer
Observer
2,736 Views
Registered: ‎04-11-2018

Re: Migrating from PetaLinux 2017.4 to 2018.1 - extra hoops to jump through

I'm glad I could help and your thanks is very much appreciated!

The more I work with the xilinx software, the more I think "surely someone else has come across this problem already?!". I'm trying to be good about posting solutions I come up with so that other people don't waste the same time I have.

So when you inevitably solve a problem you haven't seen a post about, please do share!

Cheers,

Iain
Highlighted
Observer
Observer
1,503 Views
Registered: ‎03-28-2019

Re: Migrating from PetaLinux 2017.4 to 2018.1 - extra hoops to jump through

I just got the same problem and followed what you instructed and problem was fixed. 

Thanks for your share. 

0 Kudos
Highlighted
Visitor
Visitor
453 Views
Registered: ‎08-06-2019

Re: Migrating from PetaLinux 2017.4 to 2018.1 - extra hoops to jump through

I found tha same problem.

In my case  the cause of the problem  was the u-boot environment saved on qspi flash and  produced with previous petalinux compilation.

The solution was to restore the default  u-boot env.

Zynq> env default -a
## Resetting to default environment

 

0 Kudos