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 <kra...@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.looijm...@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@0(???) { partition1; partition2; partition3; .... >> }. *How >> > do I know what to actually write for the flash@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 < >> sande...@xilinx.com >> > <mailto:sande...@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@zcu102-zynqmp <mailto:root@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:kra...@gmail.com <mailto: >> kra...@gmail.com>] >> > *Sent:* Thursday, November 16, 2017 2:11 PM >> > *To:* Sandeep Gundlupet Raju <sande...@xilinx.com >> > <mailto:sande...@xilinx.com>> >> > *Cc:* meta-xilinx@yoctoproject.org <mailto: >> meta-xilinx@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 >> > <sande...@xilinx.com <mailto:sande...@xilinx.com>> wrote:____ >> > >> > ____ >> > >> > *Thanks,*____ >> > >> > *Sandeep*____ >> > >> > ____ >> > >> > *From:*meta-xilinx-boun...@yoctoproject.org >> > <mailto:meta-xilinx-boun...@yoctoproject.org> >> > [mailto:meta-xilinx-boun...@yoctoproject.org >> > <mailto:meta-xilinx-boun...@yoctoproject.org>] *On Behalf Of >> *Giordon >> > Stark >> > *Sent:* Thursday, August 17, 2017 6:10 PM >> > *To:* meta-xilinx@yoctoproject.org <mailto: >> meta-xilinx@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.looijm...@topicproducts.com >> Website: www.topicproducts.com >> >> Please consider the environment before printing this e-mail >> >> >> >> -- >> _______________________________________________ >> meta-xilinx mailing list >> meta-xilinx@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-xilinx >> > -- Giordon Stark
-- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
