MiniZed Petalinux 2010.1

Hi Hartley,

You are correct that the MiniZed BSP build script also builds the underlying hw platform in Vivado.  The build script senses if the hw project has been built and runs Vivado in the background to build it.  This also means that the hw project only has to be built once.  The next time the BSP build script is run it will just grab the Vivado xsa and bitstream files and import them into the PetaLinux project.  This saves significant time.

A PetaLinux build requires an active internet connection, and the "ERROR about speexdsp-1.2rc3-r0 not being found" error you mention could be the result of a few things:

• Your internet connection having problems
• The server where the speexdsp package is hosted is having internet connection problems
• The speexdsp package files have moved to a different server, or the version has changed, but the package build recipe has not be updated

Sometimes this warning/error will fix itself on a retry of the build.  Quite often this error will fix itself (e.g. the package recipe will find alternate hosting sites for the package sources) while the BSP is being built. 

--Tom

Hi Hartley,

You are correct that the MiniZed BSP build script also builds the underlying hw platform in Vivado.  The build script senses if the hw project has been built and runs Vivado in the background to build it.  This also means that the hw project only has to be built once.  The next time the BSP build script is run it will just grab the Vivado xsa and bitstream files and import them into the PetaLinux project.  This saves significant time.

A PetaLinux build requires an active internet connection, and the "ERROR about speexdsp-1.2rc3-r0 not being found" error you mention could be the result of a few things:

• Your internet connection having problems
• The server where the speexdsp package is hosted is having internet connection problems
• The speexdsp package files have moved to a different server, or the version has changed, but the package build recipe has not be updated

Sometimes this warning/error will fix itself on a retry of the build.  Quite often this error will fix itself (e.g. the package recipe will find alternate hosting sites for the package sources) while the BSP is being built. 

--Tom

Should I just kill the build and run the ./make_minized.sh script again?

Killing the PetaLinux build is sometimes tricky.  It does not like to be killed and will often hang.  If you do that you should reboot to be sure there aren't any stray processes still running.

--Tom

Hmmm. A Ctrl-C didn't kill the build. It appears to have restarted it.

Looking at the log it looks like it has restarted a couple times. Is this normal?

The ./make_minized.sh script finally finished but I did a Ctrl+C a number of times when it appeared to hang while compiling the kernel. Not sure what effect that will have.

I think running the script again and just letting it try to finish overnight may be worthwhile. What is the best way to ensure that the build is clean?

The best way to do a clean and rebuild is the following concatenated (&&) commands:

$ petalinux-build -x mrproper --force && petalinux-build

The BSP build script will retry the 'petalinux-build' step once on a failure:

# Sometimes the build fails because of fetch or setscene issues, so we try another time

petalinux-build -c ${PETALINUX_BUILD_IMAGE} || petalinux-build -c ${PETALINUX_BUILD_IMAGE}

A second run of the ./make_minized.sh script went much better.

It actually renamed the first project directory and created a new one but it finished with no issues in less than an hour.

Now I have a stupid question.... What do I need to do to boot the created files?

I would like to jtag boot the board first to make sure it works then I would like to put the new files on the MiniZed eMMC and boot it normally.

Thanks for the help trying to figure this out. I still don't quite get how petalinux works (I'm more familiar with Buildroot) but at least I'm getting something to start with.

Hartley

In the petalinux/documentation/minized directory I found a how_to_boot.txt file.

I tried the first option (1- Boot from JTAG) and get this:

---

$ xsdb boot_jtag_INITRD_MINIMAL.tcl

rlwrap: warning: your $TERM is 'xterm-256color' but rlwrap couldn't find it in the terminfo database. Expect some problems.

attempting to launch hw_server                                                                                                                                                                                             

****** Xilinx hw_server v2020.1

  **** Build date : May 27 2020 at 20:33:44

    ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

INFO: hw_server application started

INFO: Use Ctrl-C to exit hw_server application                                                                                                                                                                             

INFO: To connect to this hw_server instance use url: TCP:127.0.0.1:3121                                                                                                                                                    

INFO: Configuring the FPGA...                                                                                                                                                                                              

INFO: Downloading bitstream: ./pre-built/linux/implementation/download.bit to the target.                                                                                                                                  

mctrlval=30800100                                                                                                                                                                                                          

INFO: Downloading ELF file: ./pre-built/linux/images/zynq_fsbl.elf to the target.                                                                                                                                          

INFO: Downloading ELF file: ./pre-built/linux/images/u-boot.elf to the target.                                                                                                                                             

INFO: Loading image: ./pre-built/linux/images/system.dtb at 0x00100000                                                                                                                                                     

INFO: Loading image: ./pre-built/linux/images/image_INITRD_MINIMAL.ub at 0x04000000

---

Then it just hangs.

On the serial port I got this:

---

U-Boot 2020.01 (Nov 30 2020 - 22:46:40 +0000)

CPU:   Zynq 7z007s

Silicon: v3.1

DRAM:  ECC disabled 512 MiB

Flash: 0 Bytes

NAND:  0 MiB

MMC:   mmc@e0100000: 0, mmc@e0101000: 1

Loading Environment from SPI Flash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 4 KiB, total 16 MiB

*** Warning - bad CRC, using default environment

In:    serial@e0001000

Out:   serial@e0001000

Err:   serial@e0001000

Net:   No ethernet found.

Hit any key to stop autoboot:  2

---

It's hung also.

It "looks" like the PL Red/Green LED man be blinking but it's hard to tell.

Getting another cup of coffee maybe something will happen...

OK. It finally did the JTAG boot shortly after I posted the last message. I guess I just got impatient waiting for the image_INITRD_MINIMAL.ub to load.

There doesn't appear to be much you can do with the minimal initrd. But, it looks like the (1) boot method is working.

I then tried the 2- Boot from QSPI (u-boot, minimal kernel & INITRD) method. That also takes forever to flash the QSPI but at least you see something is happening... That also worked. From the boot messages it appears to be exactly the same kernel and INITRD as the (1) boot method.

Now, on to the other boot methods.

Questions...

Method 3 appears the just be a version of 2 where u-boot is in the QSPI and the kernel and INITRD are in the eMMC. Is this correct?

Methods 4 and 5 also appear similar. Both have a Ext4 rootfs and I assume the same kernel as the other methods. They just store the data in different memories.

For a "real world" use, what is the recommended way to store the data? I assume u-boot must be in the QSPI and the rootfs should be in the eMMC (more storage space), but is the kernel better to have in the QSPI or the eMMC?

Thanks,

Hartley

Hmm... Method 4- Boot from QSPI (u-boot) and EMMC (kernel & Ext4 rootfs) hangs. Here's the end of the boot log:

---

Loading compiled-in X.509 certificates

mmc0: new high speed MMC card at address 0001

of-fpga-region fpga-full: FPGA Region probed

mmcblk0: mmc0:0001 Q2J55L 7.09 GiB

mmcblk0boot0: mmc0:0001 Q2J55L partition 1 16.0 MiB

mmcblk0boot1: mmc0:0001 Q2J55L partition 2 16.0 MiB

mmcblk0rpmb: mmc0:0001 Q2J55L partition 3 4.00 MiB, chardev (245:0)

mmcblk0: p1 p2

mmc1: SDHCI controller on e0100000.mmc [e0100000.mmc] using ADMA

hctosys: unable to open rtc device (rtc0)

of_cfs_init

of_cfs_init: OK

cfg80211: Loading compiled-in X.509 certificates for regulatory database

cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

platform regulatory.0: Direct firmware load for regulatory.db failed with error -2

ALSA device list:

  No soundcards found.

Waiting for root device /dev/mmcblk1p2...

cfg80211: failed to load regulatory.db

mmc1: queuing unknown CIS tuple 0x80 (2 bytes)

mmc1: queuing unknown CIS tuple 0x80 (3 bytes)

mmc1: queuing unknown CIS tuple 0x80 (3 bytes)

mmc1: queuing unknown CIS tuple 0x80 (7 bytes)

mmc1: queuing unknown CIS tuple 0x80 (3 bytes)

mmc1: queuing unknown CIS tuple 0x80 (6 bytes)

random: fast init done

mmc1: new high speed SDIO card at address 0001

brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2

brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50

---

But, the kernel is not hung. If I plug in a USB stick I get:

---

usb 1-1: new high-speed USB device number 2 using ci_hdrc

usb-storage 1-1:1.0: USB Mass Storage device detected

scsi host0: usb-storage 1-1:1.0

scsi 0:0:0:0: Direct-Access     General  UDisk            5.00 PQ: 0 ANSI: 2

sd 0:0:0:0: Attached scsi generic sg0 type 0

sd 0:0:0:0: [sda] 7987200 512-byte logical blocks: (4.09 GB/3.81 GiB)

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] No Caching mode page found

sd 0:0:0:0: [sda] Assuming drive cache: write through

sda:

sd 0:0:0:0: [sda] Attached SCSI removable disk

---

Not sure what the issue is. Any ideas?

Thanks,

Hartley