[meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card
Giordon Stark
kratsg at gmail.com
Fri Jul 20 10:49:38 PDT 2018
Hi all,
A brief update on the progress. After going back and forth with Xilinx a
lot -- we finally found a series of patches to apply on top of rocko that
resolve the PLL hang we've been observing for a long time (~since a week
after my last response in this email thread).
I'd like to double-back over to the erase block size. Unfortunately, I'm
very confused about why Linux and U-boot are reporting different sizes (or
maybe I'm confused).
Referring to this kernel log for a qspi boot that failed:
https://gist.github.com/kratsg/b93fb762d956c148dd0d26f9028419a3
I see these two blocks:
*u-boot*
ZynqMP> sf probe
zynqmp_qspi_ofdata_to_platdata: CLK 124999999
SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total
512 MiB
*linux*
[ 2.738079] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2.745816] m25p80 spi0.0: found mt25qu02g, expected n25q512a
[ 2.751774] m25p80 spi0.0: mt25qu02g (524288 Kbytes)
[ 2.756677] 3 ofpart partitions found on MTD device spi0.0
[ 2.762131] Creating 3 MTD partitions on "spi0.0":
[ 2.766907] 0x000002000000-0x000003000000 : "kernel"
[ 2.772323] 0x000003000000-0x000004000000 : "device-tree"
[ 2.778083] 0x000004000000-0x000008000000 : "rootfs"
U-boot tells me the erase block size is 128 KiB (0x2_0000) but this seems
to be incorrect as I see lines like these later on
[ 4.438252] jffs2: Node at 0x00001bfc with length 0x00000435 would run
over the end of the erase block
[ 4.447494] jffs2: Perhaps the file system was created with the wrong
erase size?
[ 4.454974] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c00: 0x0435 instead
[ 4.464418] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c04: 0x9438 instead
[ 4.473878] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c08: 0x0013 instead
[ 4.483348] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c0c: 0x0006 instead
[ 4.492803] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c10: 0x81ed instead
[ 4.502267] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c18: 0x4398 instead
[ 4.511722] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c28: 0x5000 instead
[ 4.521184] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c2c: 0x03f1 instead
[ 4.530645] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c30: 0x1000 instead
[ 4.540107] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x00001c34: 0x0006 instead
[ 4.549567] jffs2: Further such events for this erase block will not be
printed
However, in the above guide, it was set to 0x2000 (8 KiB?) so I tried that,
and get similar "magic bitmask not found" errors. I'm at a loss at how to
figure out the correct eraseblock size here.
I am using rocko branches, 2017.3 for what concerns the kernel/sdk.
Giordon
On Fri, Nov 17, 2017 at 8:10 AM Giordon Stark <kratsg at gmail.com> wrote:
> Hi Mike,
>
> Thanks -- I was wondering about this, since it's been a struggle to find
> information about this. We do have two gotchas that might affect whether we
> can use SPL or not.
>
> 1) we have a custom FSBL we need to use for the board [custom power-on
> sequence, clocks, etc...] that the engineers wrote
> 2) we do not have a working SD card on the board, a problem with the
> placement process
>
> So this gives me a question or two:
>
> - how do I partition the QSPI without being able to initially boot linux
> on the board using SD Card boot?
> - do I edit my device tree to define the partitions for the kernel to be
> aware of -- and how do I make sure I partition exactly like defined?
>
> I will take a look at meta-topic.
>
> Giordon
>
>
> On Fri, Nov 17, 2017 at 2:01 AM Mike Looijmans <mike.looijmans at topic.nl>
> wrote:
>
>> Much of the zynq booting information on the Xilinx website focuses on
>> petalinux and the Xilinx SDK and doesn't apply to the Openembedded/Yocto
>> toolflow at all.
>>
>> The boot flow can be mostly the same as any ARM based board, but Xilinx
>> doesn't provide that information anywhere. You can find an example in our
>> repo
>> though, https://github.com/topic-embedded-products/meta-topic which
>> applies to
>> the Topic boards, but this should work with the Xilinx boards as well if
>> you
>> use the appropriate configs and devicetrees.
>>
>> The QSPI boot procedure for the ZynqMP using Yocto/OE should be:
>>
>> Partition the QSPI:
>> - boot.bin (192k)
>> - ATF (128k or whatever your sector size is)
>> - u-boot.bin (768k)
>> - "rootfs"
>>
>> Building u-boot SPL using OE should deliver boot.bin and u-boot.img. This
>> should also put the PMU firmware into boot.bin using the configuration
>> option
>> in u-boot (this isn't done for Xilinx boards by default, see meta-topic
>> how to
>> patch that in).
>>
>> The arm-trusted-firmware binary (not the elf but the atf-qspi.bin that is
>> produced by the arm-trusted-firmware recipe) goes into the second
>> partition.
>>
>> This should get the bootloader up and running.
>>
>> If you partition the rootfs using UBI, you can put the kernel, devicetree
>> and
>> rootfs and FPGA bitstream in there. u-boot can read UBI filesystems so you
>> don't need separate partitions for these.
>>
>>
>> Tip: Boot to Linux using SD card, then program the QSPI flash using
>> "flashcp"
>> commands and "ubiformat" for the root.
>>
>>
>> Note that you don't need FSBL or bootgen anywhere in this flow.
>>
>>
>> On 17-11-17 07:17, Giordon Stark wrote:
>> > Hi Sandeep,
>> >
>> > Thanks for the detail! Is this not documented at all anywhere on a
>> Xilinx
>> > wiki? I'm surprised, given the slight complexity in the steps, that this
>> > procedure isn't as straightforward as for an SD Card boot [but maybe
>> that's
>> > me]. I suppose I still have a few more questions using concrete
>> examples:
>> >
>> > My BIF looks like
>> >
>> > //arch = zynqmp; split = false; format = BIN
>> > the_ROM_image:
>> > {
>> > [fsbl_config]a53_x64
>> >
>> [bootloader]C:\Users\kratsg\Desktop\zu19eg_3.sdk\fsbl\Debug\fsbl.elf
>> > [destination_cpu = pmu]Z:\gfex-prototype3\pmu-gfex-prototype3.elf
>> > [destination_device =
>> >
>> pl]C:\Users\kratsg\Desktop\zu19eg_3.sdk\zcu19eg_top_hw_platform_0\zcu19eg_top.bit
>> > [destination_cpu = a53-0, exception_level = el-3,
>> > trustzone]Z:\gfex-prototype3\arm-trusted-firmware.elf
>> > [destination_cpu = a53-0, exception_level =
>> > el-2]Z:\gfex-prototype3\u-boot.elf
>> > }
>> >
>> > *Why does the BIF not contain the kernel image - as you would do so in
>> the
>> > procedure for SDCard boot?*
>> > *
>> > *
>> > Next, our DTS files are here:
>> >
>> https://github.com/kratsg/meta-l1calo/tree/master/conf/machine/boards/gfex/prototype3
>> .
>> > Specifically, I'm looking at "spi1 = &qspi" in system-top.dts and I will
>> > probably need to add the QSPI partitions under this. The point is that
>> I make
>> > a flash node flash at 0(???) { partition1; partition2; partition3; ....
>> }. *How
>> > do I know what to actually write for the flash at 0 stuff? It's not clear
>> to me
>> > how large these blocks should be and how to make sure the offsets are
>> correct
>> > and can be picked up via u-boot and so on. [I looked here:
>> > http://www.wiki.xilinx.com/Linux+ZynqMP+GQSPI+Driver as an example
>> since your
>> > email about creating MTD partitions wasn't rendered correctly for me,
>> so I
>> > couldn't read that part, missing an image or something else?]*
>> > *
>> > *
>> > *Finally, I'm a little confused about how you're able to have a Linux
>> prompt
>> > without the kernel or filesystem.* Since it looks like you're
>> programming QSPI
>> > with the devicetree, the kernel, and the filesystem -- how would you
>> have a
>> > linux prompt before linux is on there? Chicken before the egg? Is the
>> > procedure that you flash the board with the BOOT.bin using the XSDK,
>> get the
>> > u-boot prompt, and program the QSPI from u-boot prompt?
>> >
>> > Thanks!
>> >
>> > Giordon
>> >
>> > On Thu, Nov 16, 2017 at 11:16 PM Sandeep Gundlupet Raju <
>> SANDEEPG at xilinx.com
>> > <mailto:SANDEEPG at xilinx.com>> wrote:
>> >
>> > Hi Giordon,____
>> >
>> > __ __
>> >
>> > $ vim boota53.bif //Add below content____
>> >
>> > __ __
>> >
>> > the_ROM_image:____
>> >
>> > {____
>> >
>> > [fsbl_config] a53_x64____
>> >
>> > [pmufw_image] <PATH_TO_IMAGES>/pmu_fw.elf____
>> >
>> > [bootloader] <PATH_TO_IMAGES>/zynqmp_fsbl.elf____
>> >
>> > [destination_device=pl] <PATH_TO_IMAGES>/design_1_wrapper.bit____
>> >
>> > [destination_cpu=a53-0] <PATH_TO_IMAGES>/bl31.elf____
>> >
>> > [destination_cpu=a53-0] <PATH_TO_IMAGES>/u-boot.elf____
>> >
>> > }____
>> >
>> > __ __
>> >
>> > Run below commands to generate the BOOT.bin____
>> >
>> > $ source vivado/setting.sh____
>> >
>> > $ bootgen -image boota53.bif -arch zynqmp -w -o i BOOT.bin ____
>> >
>> > __ __
>> >
>> >
>> > Using QSPI JFFS2 partition as root file system____
>> >
>> > __ __
>> >
>> > Linux rootfs can be mounted from JFFS2 partition on the qspi. This
>> > document briefs about the steps to use qspi JFFS2 rootfs. This
>> procedure
>> > describes generic flow, which can be more simplified if you are
>> using
>> > petalinux.____
>> >
>> > __ __
>> >
>> >
>> > Enabling JFFS2 support in Linux (enabled by default)____
>> >
>> > __ __
>> >
>> >
>> > Enable Generic QSPI controller driver____
>> >
>> > CONFIG_SPI_ZYNQMP_GQSPI:
>> │____
>> >
>> > │ │____
>> >
>> > │ Enables Xilinx GQSPI controller driver for Zynq UltraScale+
>> MPSoC.
>> > │____
>> >
>> > │ │____
>> >
>> > │ Symbol: SPI_ZYNQMP_GQSPI [=y] │____
>> >
>> > │ Type : tristate │____
>> >
>> > │ Prompt: Xilinx ZynqMP GQSPI controller │____
>> >
>> > │ Location: │____
>> >
>> > │ -> Device Drivers │____
>> >
>> > │ -> SPI support (SPI [=y]) │____
>> >
>> > │ Defined at drivers/spi/Kconfig:716 │____
>> >
>> > │ Depends on: SPI [=y] && SPI_MASTER [=y] && HAS_DMA [=y]____
>> >
>> > __ __
>> >
>> >
>> > Enable JFFS2 file system support.____
>> >
>> > image001.png____
>> >
>> >
>> > __ __
>> >
>> > __ __
>> >
>> >
>> > Create MTD partitions for the QSPI____
>> >
>> > MTD partitions can be defined in the qspi device tree node as flash
>> > device. Example of qspi partition is as below:____
>> >
>> > ____
>> >
>> > These partition can be seem from Linux prompt:____
>> >
>> > root at zcu102-zynqmp <mailto:root at zcu102-zynqmp>:~# cat /proc/mtd
>> > dev: size erasesize name
>> > mtd0: 00200000 00002000 "qspi-fsbl-uboot"
>> > mtd1: 01000000 00002000 "qspi-linux"
>> > mtd2: 00020000 00002000 "qspi-device-tree"
>> > mtd3: 04000000 00002000 "qspi-rootfs" ____
>> >
>> >
>> > __ __
>> >
>> >
>> > Preparing and populating rootfs in mtd partition____
>> >
>> > __ __
>> >
>> > A jffs2 filesystem image can be created using mtd utilities, which
>> can be
>> > then flashed to the desired mtd partition (mtd3 in our case). While
>> > creating jffs2 image, make sure to pass correct eraseblock size
>> (can be
>> > found by sf probe 0 0 0 command on u-boot prompt).____
>> >
>> > __ __
>> >
>> >
>> > Generating jffs2 image____
>> >
>> > In yocto project you can specify following two parameters in the
>> > local.conf:____
>> >
>> > IMAGE_FSTYPES += " jffs2"____
>> >
>> > JFFS2_ERASEBLOCK = "0x2000"____
>> >
>> > This will generate <image name>.jffs2 file in the deploy area.____
>> >
>> > __ __
>> >
>> > __ __
>> >
>> > Separately if you have tar.gz or rootfs directory, you can generate
>> the
>> > rootfs image on the host machine by following command____
>> >
>> > mkfs.jffs2 --root=<rootfs directory location> --eraseblock=<erase
>> block
>> > size> -p -o rootfs.jffs2____
>> >
>> >
>> > __ __
>> >
>> > __ __
>> >
>> >
>> > Flashing jffs2 image on the partition____
>> >
>> > It is possible to flash the generated image from u-boot as well as
>> from
>> > the Linux prompt.____
>> >
>> > It is necessary to clean /erase the flash before writing new data
>> (though
>> > Linux will take care).____
>> >
>> > __1)__From Linux prompt:____
>> >
>> > __a.__Erase the entire partition and also format it to jffs2____
>> >
>> > # flash_eraseall -j /dev/mtd3____
>> >
>> > __b.__Write the jffs2 image on mtd 3 partition____
>> >
>> > # flashcp <path to rootfs.jffs2> /dev/mtd3____
>> >
>> > __ __
>> >
>> > __2)__From u-boot prompt____
>> >
>> > __a.__Probe the flash device____
>> >
>> > > sf probe 0 0 0____
>> >
>> > __b.__Erase the entire partition (here you need to know the offset
>> and
>> > size)____
>> >
>> > > sf erase 0x1300000 0x4000000____
>> >
>> > __c.__Load the jffs2 image in the memory location (ddr) from sd card
>> > (other tftp from network)____
>> >
>> > > fatload mmc 0 0x10000000 rootfs.jffs2____
>> >
>> > __d.__Write the image from the memory on to the flash____
>> >
>> > > sf write 0x10000000 0x1300000 ${filesize}____
>> >
>> > __ __
>> >
>> > __3)__From Linux prompt with tar.gz image (not jffs2)____
>> >
>> > Rootfs content can be simply copied after mounting jffs2
>> partition____
>> >
>> > __a.__Erase the entire partition and also format it to jffs2
>> (mandatory) ____
>> >
>> > # flash_eraseall -j /dev/mtd3____
>> >
>> > __b.__Determine the location of rootfs.tar.gz image (can be on sd
>> card or
>> > network. Assuming sd card for now)____
>> >
>> > __i.__Mount the sd card____
>> >
>> > # mount /dev/mmcblk0p1 /media____
>> >
>> > __c.__Mount jffs2 partition on the /mnt____
>> >
>> > # mount -t jffs2 /dev/mtdblock3 /mnt____
>> >
>> > __d.__Copy the file system to the jffs2 partition____
>> >
>> > # cd /mnt/____
>> >
>> > # tar zxvf /media/rootfs.tar.gz (choose appropriate path here).____
>> >
>> >
>> > Setting kernel rootfs ____
>> >
>> > __ __
>> >
>> > One can use rootfs from the jffs2 partition regardless of the
>> boot-mode.
>> > Rootfs path can be specified to kernel through bootargs. One can
>> change
>> > the bootargs from the u-boot prompt.____
>> >
>> > For sd-boot, the the bootargs for the root partition is set by
>> sdroot0
>> > variable. You can change the sdroot0 variable to add following to
>> the
>> > bootargs____
>> >
>> > root=/dev/mtdblock3 rw rootwait rootfstype=jffs2 ____
>> >
>> > u-boot> setenv sdroot0 "setenv bootargs earlycon clk_ignore_unused
>> > root=/dev/mtdblock3 rw rootwait rootfstype=jffs2"____
>> >
>> > u-boot> saveenv # for next boot____
>> >
>> > u-boot> run sdboot____
>> >
>> > __ __
>> >
>> > Similarly for other bootmodes make sure that the bootargs is set
>> properly.____
>> >
>> > __ __
>> >
>> > *Thanks,____*
>> >
>> > *Sandeep____*
>> >
>> > __ __
>> >
>> > *From:*Giordon Stark [mailto:kratsg at gmail.com <mailto:
>> kratsg at gmail.com>]
>> > *Sent:* Thursday, November 16, 2017 2:11 PM
>> > *To:* Sandeep Gundlupet Raju <SANDEEPG at xilinx.com
>> > <mailto:SANDEEPG at xilinx.com>>
>> > *Cc:* meta-xilinx at yoctoproject.org <mailto:
>> meta-xilinx at yoctoproject.org>
>> > *Subject:* Re: [meta-xilinx] [ZynqMP] Booting from QSPI instead of
>> SD Card____
>> >
>> > __ __
>> >
>> > Thanks a lot Sandeep,____
>> >
>> > __ __
>> >
>> > Do you know what you are supposed to do with the filesystem? E.G.
>> if you
>> > create a bif file, that contains what specifically? The linked User
>> Guide
>> > seems to indicate not using that, but I'm unclear. I suppose I need
>> the
>> > following in order:____
>> >
>> > __ __
>> >
>> > - FSBL____
>> >
>> > - PMU____
>> >
>> > - ATF____
>> >
>> > - uramdisk.gz____
>> >
>> > - devicetree____
>> >
>> > - u-boot____
>> >
>> > - Image____
>> >
>> > __ __
>> >
>> > Correct?____
>> >
>> > __ __
>> >
>> > Giordon____
>> >
>> > On Thu, Aug 17, 2017 at 9:46 PM Sandeep Gundlupet Raju
>> > <SANDEEPG at xilinx.com <mailto:SANDEEPG at xilinx.com>> wrote:____
>> >
>> > ____
>> >
>> > *Thanks,*____
>> >
>> > *Sandeep*____
>> >
>> > ____
>> >
>> > *From:*meta-xilinx-bounces at yoctoproject.org
>> > <mailto:meta-xilinx-bounces at yoctoproject.org>
>> > [mailto:meta-xilinx-bounces at yoctoproject.org
>> > <mailto:meta-xilinx-bounces at yoctoproject.org>] *On Behalf Of
>> *Giordon
>> > Stark
>> > *Sent:* Thursday, August 17, 2017 6:10 PM
>> > *To:* meta-xilinx at yoctoproject.org <mailto:
>> meta-xilinx at yoctoproject.org>
>> > *Subject:* [meta-xilinx] [ZynqMP] Booting from QSPI instead of
>> SD Card____
>> >
>> > ____
>> >
>> > Hi,____
>> >
>> > ____
>> >
>> > Many thanks to the folks here for helping me get the SD Card
>> booting
>> > working (especially with the data duplicator command to burn
>> the SD
>> > card correctly with partitions). What's the general procedure
>> for
>> > having the board boot from the QSPI instead of the SD card? Do
>> you
>> > need specific software on the computer and transfer over
>> JTAG?____
>> >
>> > Refer UG1209
>> >
>> https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug1209-embedded-design-tutorial.pdf
>> > ____
>> >
>> > ____
>> >
>> > It would be great if someone could point me to a set of
>> instructions.____
>> >
>> > ____
>> >
>> > Giordon____
>> >
>> >
>> >
>>
>>
>>
>> Kind regards,
>>
>> Mike Looijmans
>> System Expert
>>
>> TOPIC Products
>> Materiaalweg 4, NL-5681 RJ Best
>> Postbus 440, NL-5680 AK Best
>> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
>> E-mail: mike.looijmans at topicproducts.com
>> Website: www.topicproducts.com
>>
>> Please consider the environment before printing this e-mail
>>
>>
>>
>> --
>> _______________________________________________
>> meta-xilinx mailing list
>> meta-xilinx at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
> --
Giordon Stark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180720/041e3bf0/attachment-0001.html>
More information about the meta-xilinx
mailing list