PetaLinux SD boot

Hi gpsat,

I guess I am a bit confused by what you are trying to accomplish.  From what I see in your post above, it looks like there is a mix of methodologies being applied here.  Using system.bit.bin is an advanced alternate development methodology that we experimented with for MicroZed which allows the PL bitstream to be updated independent of the FSBL or U-Boot executables since the bitstream is loaded by U-boot rather than by the FSBL.

If you want to follow the PetaLinux development methodology which is the one that Xilinx recommends, then eventually you will reach a step that will allow for your system FSBL, the PL bitstream, and the U-Boot executable to all be packaged into a boot.bin container file.  Once you have reached the point in the development process where you have all 3 of the precursor files built, the PetaLinux command to package them into boot.bin will be something like this:

petalinux-package --boot --fsbl /tftpboot/zynq_fsbl.elf --fpga ../design_1_wrapper.bit --uboot=/tftpboot/u-boot.elf

Using that approach, you will not need to use a system.bit.bin file and perhaps you are getting snagged by a stale U-Boot environment partition.  I saw another post from you here:

http://microzed.org/content/open-source-linux-system-qspi-programming-tutorial-fails

Please go through that other thread first since clearing the U-Boot environment variables might get you past this issue.  If it does not resolve your issue, let me know the details of what you find.

Regards,

-Kevin

Okay, I'm not getting anything different now.

I'm certain it's just that I haven't found a single guide for setting up the microZed that doesn't presume extensive petaLinux experience. And thus when the guides finish with "And now it's easy to put the files on the SD card and boot" I'm largely having to guess which files it's talking about.

Can you point me to a guide that will step me though making those three files then deploying the result to the microZed?

So I was wondering if the "MicroZed 7020 Open Source Linux In System QSPI Programming Tutorial" as mentioned in the other thread was what was poisoning the U-Boot env variabels, so I did the full wipe as described in the other thread then put the boot.bin created by the command you posted (petalinux-package ...) on a sd card and set the jumpers to boot from the SD card.

Nothing happens, not a single character is printed to the terminal.



While trying to think of things to get this all working I noticed I hadn't gone through the 4 tutorials (01_MicroZed_Zynq_Intro_2014_2_01 to 04_MicroZed_FSBL_Boot_2014_2_01) which I just did (except for the JTAG bits, not a piece of hardware we have lying around conveniently right now) and all of those worked fine.


As to what my end goal is:
We want linux on the mircoZed with a few applications of our writing doing their thing. The petaLinux flow of things looks really nice and reliable. As yet I'm not wanting to anything a non-standard way, I've gone as far as using a centos VM inside my Ubuntu box because of some issues running petalinux in ubuntu.


So I'm currently wondering:
A) What is the correct way to make those three precursor files?
B) Is there meant to be any files along side the BOOT.BIN file on the SD card for booting from SD card?

Hi gpsat,

The simplest way to accomplish what you want is to download the PetaLinux 2014.2 BSP from the reference design/tutorial area for MicroZed, and then refer to the Xilinx User Guide 977 for 2014.2 to install the BSP.

http://www.xilinx.com/support/documentation/sw_manuals/petalinux2014_2/ug977-petalinux-getting-started.pdf

To build the system for a specific board, refer to the Xilinx User Guide 980:

http://www.xilinx.com/support/documentation/sw_manuals/petalinux2014_2/ug980-petalinux-board-bringup.pdf

If you prefer, there is a PetaLinux tutorial on ZedBoard.org for the Zynq Mini-ITX board.  While you cannot use the support files for the MicroZed, all of the software instructions are applicable.

The only files you need to copy to the top-level directory of the microSD card are the BOOT.BIN and the image.ub.  Configure the mode switches for SD boot on your board and you should be all set.

Ron

Going through UG 977 they have this pearl of a line at the end of page 15:

For Zynq, you can follow section Boot Pre-built Images from SD Card for Zynq to SD boot the rebuilt images. Instead of using the prebuilt image.ub, use the rebuilt one from <plnx-proj-root>/images/linux/image.ub

It's just a shame that we haven't been told how to build a boot.bin file. But I bet that is only an issue because now I need to figure out how to deal with a larger image.ub.

But if I can't solve that I'll start a new thread.

Reduced the un-needed library files being included and now the image is small enough to fit in. Things are running, very happy.

So now I have two questions remaining:
a) How to increase the size limitations on the image, others don't appear to have gotten any help on that previously (http://zedboard.org/content/petalinux-boot-error-zedboard)
b) How to deploy my image to the QSPI flash, sd cards aren't the most reliable of interfaces.

Focusing on the size restriction first.

The best set of instructions I could find was http://forums.xilinx.com/t5/Embedded-Linux/Petalinux-kernel-not-loading/m-p/502122#M10150 (post #3) but it is aimed at ZedBoard not microZed. But following those instructions doesn't help me.

testing

And here I was getting hopeful that someone had something to say.

You can try reading this chapter "Booting Linux from QSPI" in the "Booting PicoZed using QSPI and eMMC" found here: http://zedboard.org/content/booting-picozed-using-qspi-and-emmc-v21 

It tells you how to get the files into the qspi flash in detail, but the 'power up with the switches set to qpsi' step is a bit vague.  I am not sure if our board had the uboot env overwritten or corrupted, but there was no command that told it to boot from qspi, so I did it by hand, something like: echo Running QSPI Boot && sf probe 0 && sf read ${clobstart} 0x520000 0x880000 && bootm ${clobstart}

The 0x520000 could be different in your system, you'd want to check the output of your 'cat /proc/mtd' command to see where the kernel partition starts.