Questions for Boot Linux From QSPI for Arrow CycloneV SoC Kit

momoxinduop · May 3, 2016, 1:07am

Hi all,
Thanks in advance for your time in this post, and possible further comments. Since I would like to describe my question as detailed as possible, this post is pretty long…

My group purchased an Arrow CycloneV SoC Kit at the end of last year, and wanted to do some investigation on further product development using the core chip. My boss spent several months on it, and failed to boot it using QSPI (due to safety requirement by our customer, we can’t use SD card). So he thrown it to me !-_-! And, me too, still fails to boot it from QSPI after almost 2 months’ struggle.

My tools are Quartus 14.0, SoC EDS 14.0, and Ubuntu 12.04.5 desktop Linux. What I have done is listed as follows:

1.Generate preloader and .dtb

Compile the hardware design provided by the Arrow SoC workshop, which is also mentioned by the document “BootTheArrowSoCKitFromQSPI” below:
https://rocketboards.org/foswiki/view/Documentation/BootTheArrowSoCKitFromQSPI

I strictly follows the instructions in Section 1, including select ‘BOOT_FROM_QSPI’ in bsp-editor, but except that I stopped after step 4, because actually when you run ‘make’ in directory software/spl, there is already a preloader named ‘preloader-mkpimage.bin’ there. I don’t know why it needs to “Navigate to the /software/spl_bsp/uboot_socfpga/spl directory, and run mkpimage -o preloader_with_header_qspi.img u-boot-spl.bin”, which actually make the boot process WORSE. I will describe this later.

Build device tree. I first modify the soc_system_board_info.xml, as listed in document
‘GSRD v13.1 – Booting from QSPI’ [Part D], which is available at
https://rocketboards.org/foswiki/view/Documentation/GSRD131QspiBoot
The modifications divide the QSPI flash into 3 partitions.

I run the following 2 commands to generate .dts and .dtb in hardware design project directory:

$ sopc2dts --input soc_system.sopcinfo
–output socfpga.dts --type dts
–board soc_system_board_info.xml
–board hps_common_board_info.xml
–bridge-removal all
–clocks
$ sopc2dts --input soc_system.sopcinfo
–output socfpga.dtb --type dtb
–board soc_system_board_info.xml
–board hps_common_board_info.xml
–bridge-removal all
–clocks

It successfully generates the .dtb file. Here, I actually tested whether this .dtb is correct by followings experiment: Rocketboard provided a pre-built SD card image, and I replaced the .dtb file in pre-built image with the one I just generated. The kit still boots successfully from SD card, and after boot, I run ‘cat /proc/mtd’, it displays:

$ cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 “Flash 0 Raw Data”
mtd1: 01000000 00010000 “Flash 1 jffs2 Filesystem”
mtd2: 00800000 00010000 “FPGA Image”

So the .dtb file generated by myself should be fine.

2.Generate u-boot, kernel and minimal root filesystem

I did this based on file ‘linux-socfpga-gsrd-13.1-src.bsx’, strictly following the document
‘GSRD v13.1 – Booting from QSPI’ [Part B and C], which is listed below:
https://rocketboards.org/foswiki/view/Documentation/GSRD131QspiBoot

After run:
$ bitbake virtual/bootloader
$ bitbake virtual/kernel
$ bitbake altera-image-minimal

I successfully got the u-boot.img, root.jffs2, and zImage.bin in build/tmp/deploy/images directory.

3.Write files to QSPI flash

I strictly follow the [Part E and F] of the above document, including change file ‘zImage.bin’ to ‘zImage’ by deleting .bin, and change BSEL[2:0] to ‘111’ for QSPI 3.3V boot.

However, when linux boots, when it passes SPL and U-Boot, it stops at ‘Starting Kernel’ in putty.
I though the kernel zImage may be the reason, so I replaced the zImage I generated with the one in pre-built SD card image provided by Rocketboard, and repeat the process ‘Write files to QSPI flash’ in 3. Then it can boot passing ‘starting kernel’, but stops very soon after that, showing some information as:

No filesystem could mount root, tried:jffs2
** Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)**
(some log information here)
(secondary_start_kernel + 0x128/0x130)
----------- Log stops here -----------------

I also tried to re-generate the preloader as I have mentioned in Step 1, by “Navigate to the /software/spl_bsp/uboot_socfpga/spl directory, and run mkpimage -o preloader_with_header_qspi.img u-boot-spl.bin”, and rewrite these files to QSPI. This action even can’t start SPL of the first step of the booting process, showing in putty:

Unsupported manufacturer 0x90
SPI probe failed

This preloader even can’t find QSPI…

Now, I feel I have no way to go, and have a lot of questions.
(1) Why the zImage generated using ‘bitbake’ by Yocto can’t even started for one inch, while the Rocketboard pre-build zImage can, although still failed at the middle of the booting process? I don’t think Yocto itself should have any problem, what is the problem here?

(2)As in 3(2), the kernel seems to be unable to know where is the root.jffs2, although I have done
‘flashcp altera-image-minimal-socfpga_cyclone5.rootfs.jffs2 /dev/mtd1’
But how does kernel know the jffs2 is at the stating address of mtd1? Similarly, commands in writing QSPI partition:

flash_erase /dev/mtd0 0 0
flash_erase /dev/mtd1 0 0
flash_erase /dev/mtd2 0 0
mtd_debug write /dev/mtd0 0 262144 preloader-mkpimage.bin
mtd_debug write /dev/mtd0 0x50000 18029 socfpga.dtb
mtd_debug write /dev/mtd0 0x60000 258060 u-boot-socfpga_cyclone5.img
mtd_debug write /dev/mtd0 0xa0000 3202832 zImage
flashcp altera-image-minimal-socfpga_cyclone5.rootfs.jffs2 /dev/mtd1
flashcp soc_system.rbf /dev/mtd2

When booting, preloader calls u-boot, and u-boot calls kernel, and kernel starts filesystem, then how does it (maybe u-boot?) know .dtb is at 0x50000 of /dev/mtd0, and zImage is at 0xa0000 of /dev/mtd0? I know 0x60000 for u-boot is assigned when you generate the preloader in bsp-editor tool.

Actually, I also tried to generate u-bbot and kernel according to document “BootTheArrowSoCKitFromQSPI” below:
https://rocketboards.org/foswiki/view/Documentation/BootTheArrowSoCKitFromQSPI
It seems for Arrow SoC kit. But it seems that the git source of files mentioned I this document has been deleted, just several clone errors.

Ah!!!

Btw, somebody told me I don’t need to generate .dtb. u-boot and kernel image separately, actually they can be generated when you compile the Linux source code “extracted from Yocto project”. But,which Yocto? Yocto has a lot of versions. And, can I ask how?..

After 2 months’ lonely fight, I found these booting issues contain a lot of magic, and I am eager to know the reasons of my questions. I know it is a shame to ask so many questions, which maybe stupid for experts. I am just a stupid beginner, and I am really hoping for some advice.

Thanks again for your time spending on this long post~~

Best Regards,

serge81 · October 5, 2017, 9:36am

Hi,momoxinduop!
I’ve faced the same problem: can’t start Linux from QSPI-flash on SoCKit board. I’m using buildroot to generate a rootfs.jffs2 (6.5 Mb). I get an error “…Unable to mount root fs on unknown-block(0,0)”. Have you managed to load Linux from QSPI?

serge81 · October 30, 2017, 12:05pm

Hi, everybody!
I’ve coped with this problem. See https://www.alteraforum.com/forum/showthread.php?t=56773&p=231301#post231301

hasanijaz · March 17, 2020, 1:08pm

I got the same issue while trying to use SOCEDS 17.1, the core problem lies with the device tree. Your device tree must contain:

`
a10_hps_i_qspi_QSPIDATA: flash@0xff809000 {
compatible = “cadence,qspi-19.1”, “cadence,qspi”, “cdns,qspi-nor”;
reg = <0xff809000 0x00000100>,
<0xffa00000 0x00000100>;
reg-names = “axi_slave0”, “axi_slave1”;
interrupt-parent = <&a10_hps_arm_gic_0>;
interrupts = <0 100 4>;
clocks = <&qspi_clk>; /* appended from boardinfo /
bus-num = <2>; / embeddedsw.dts.params.bus-num type NUMBER /
fifo-depth = <128>; / embeddedsw.dts.params.fifo-depth type NUMBER /
num-chipselect = <4>; / embeddedsw.dts.params.num-chipselect type NUMBER /
status = “okay”; / embeddedsw.dts.params.status type STRING /
bank-width = <2>;
device-width = <1>;
#address-cells = <1>; / appended from boardinfo /
#size-cells = <0>; / appended from boardinfo /
ext-decoder = <0>; / appended from boardinfo /
cdns,fifo-depth = <128>; / appended from boardinfo /
cdns,fifo-width = <4>; / appended from boardinfo /
cdns,trigger-address = <0>; / appended from boardinfo */

		flash0: n25q00@0 {
			#address-cells = <1>;	/* appended from boardinfo */
			#size-cells = <1>;	/* appended from boardinfo */
			compatible = "n25q00aa";	/* appended from boardinfo */
			reg = <0>;	/* appended from boardinfo */
			spi-max-frequency = <100000000>;	/* appended from boardinfo */
			m25p,fast-read;	/* appended from boardinfo */
			page-size = <256>;	/* appended from boardinfo */
			block-size = <16>;	/* appended from boardinfo */
			tshsl-ns = <50>;	/* appended from boardinfo */
			tsd2d-ns = <50>;	/* appended from boardinfo */
			tchsh-ns = <4>;	/* appended from boardinfo */
			tslch-ns = <4>;	/* appended from boardinfo */
			cdns,page-size = <256>;	/* appended from boardinfo */
			cdns,block-size = <16>;	/* appended from boardinfo */
			cdns,read-delay = <3>;	/* appended from boardinfo */
			cdns,tshsl-ns = <50>;	/* appended from boardinfo */
			cdns,tsd2d-ns = <50>;	/* appended from boardinfo */
			cdns,tchsh-ns = <4>;	/* appended from boardinfo */
			cdns,tslch-ns = <4>;	/* appended from boardinfo */

			partition@qspi-boot {
				label = "Boot and fpga data";
				reg = <0x0 0x2720000>;
			};

			partition@qspi-rootfs {
				label = "Root Filesystem - JFFS2";
				reg = <0x2720000 0x58E0000>;
			};
		}; //end n25q00@0 (flash0)
	}; //end flash@0xff809000 (a10_hps_i_qspi_QSPIDATA)

`