Forum Discussion

EricOpitz's avatar
EricOpitz
Icon for New Contributor rankNew Contributor
5 months ago
Solved

Agilex 5 QSPI Probe fails

Dear all,
I'm working on getting RSU running on the Agilex 5 Arrow AXE5-Eagle dev kit.
My problem regards the new version QPDS25.1. With this version I can not probe the QSPI flash. Using the old version QPDS24.2 it worked fine.
I'm following the official tutorial for the AXE5 eagle dev kit:
I've followed the tutorial exactly. When I'm booting with 24.2:
- In the U-Boot log I see "SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256 MiB". This shows that the JEDEG id can be read from the flash and it is recognized.
- In the Linux boot log I see "
[ 1.442103] spi-nor spi0.0: mt25qu02g (262144 Kbytes)
[ 1.448305] 2 fixed-partitions partitions found on MTD device 108d2000.spi.0
[ 1.455340] Creating 2 MTD partitions on "108d2000.spi.0":
[ 1.460817] 0x000000000000-0x000003fe0000 : "Boot and fpga data"
[ 1.468038] 0x000003fe0000-0x000010000000 : "Root Filesystem - JFFS2"
"
This also shows that the flash can be accessed from linux and the device shows up as /dev/mtd0
When following the 25.1 tutorial:
- I did not apply the section "Configure the FPGA with a Device Tree Overlay". But I don't think this influences communication with QSPI.
- In the U-Boot log I see no log message regarding the flash.
- In the Linux boot log I see no log message regarding the flash.
- In the U-Boot console:
$ sf probe
"Synchronous Abort" handler, esr 0x96000010, far 0x108d2000
...
I noticed that in 25.1 in the socfpga_agilex5_axe5_eagle.dts (linux-socfpga) and socfpga_agilex5.dtsi (u-boot-socfpga) have the qspi status = "disabled". I manually set it to "okay". I've recompiled u-boot, generated the linux .dtb and flashed the QSPI using JTAG. During boot, Linux now has a kernel panic, so this doesn't fix the problem.
I'm aware of the Altera tutorial for RSU (https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-5/e-series/premium/rsu/ug-rsu-agx5e-soc/#building-u-boot). Unfortunately, I don't have the premium dev kit, so I can't follow it exactly.
Kind Regards,
Eric Opitz
Fpga Devkit
  • RolandoS_Altera's avatar
    RolandoS_Altera
    5 months ago

    Hi Eric

    In 25.1 a new feature was introduced to control if you want to allow or prevent to grant the ownership of the QSPI to the HPS.

    https://cdrdv2-public.intel.com/853092/ug-813762-853092.pdf

    See section 4.2.1 and 4.12.

    Check in your hardware design if the QSPI ownership is assigned to the HPS. If this is not the case, then the SDM will reject the MBOX_QSPI_DIRECT mailbox.

    Thanks

    Rolando

6 Replies

  • tehjingy_Altera's avatar
    tehjingy_Altera
    Icon for Regular Contributor rankRegular Contributor
    5 months ago

    Hi


    I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


    Regards

    Jingyang, Teh



  • EricOpitz's avatar
    EricOpitz
    Icon for New Contributor rankNew Contributor
    5 months ago

    Hi Rolando,

    This solves the problem. Thank you for your Help!

    Kind Regards,

    Eric Opitz

  • RolandoS_Altera's avatar
    RolandoS_Altera
    Icon for Occasional Contributor rankOccasional Contributor
    5 months ago

    Hi Eric

    In 25.1 a new feature was introduced to control if you want to allow or prevent to grant the ownership of the QSPI to the HPS.

    https://cdrdv2-public.intel.com/853092/ug-813762-853092.pdf

    See section 4.2.1 and 4.12.

    Check in your hardware design if the QSPI ownership is assigned to the HPS. If this is not the case, then the SDM will reject the MBOX_QSPI_DIRECT mailbox.

    Thanks

    Rolando

  • EricOpitz's avatar
    EricOpitz
    Icon for New Contributor rankNew Contributor
    5 months ago

    Hi Teh,

    Could you please share the latest boot log that you are facing?

    Attached you find the following boot logs:

    - arrow_example_24.2_clean_boot_log.txt: I've followed the arrow tutorial 24.2 strictly.

    - arrow_example_25.1_clean_boot_log.txt: I've followed the arrow tutorial 25.1 strictly.

    - arrow_example_25.1_modified_dts_1_boot_log.txt: In addition to arrow tutorial 25.1 I've modified the dts to set the qspi status = "okay". I recompiled U-Boot and reran the quartus_pfg commands to generate the axe5_eagle_top_hps.sof and .jic and .rbf files. I also recompiled the Linux dts. I've updated the files on the SD card and updated the QSPI flash via JTAG. I ran sf probe in u-boot shell resulting in a synchronous abort.

    - arrow_example_25.1_modified_dts_2_boot_log.txt: In addition to arrow tutorial 25.1 I've modified the dts as above. I let Linux boot. The boot fails due to a kernel panic when probing the qspi flash.

    - arrow_example_25.1_modified_dts_and_24.2_sdm_boot_log.txt: In addition to arrow tutorial 25.1 I've modified the dts as above and used quartus_pfg from Quartus 24.2 to generate the axe5_eagle_top_hps.sof and .jic and .rbf files. I've update the QSPI flash via JTAG and the .rbf on SD card. All other files are from the 25.1 tutorial (u-boot-spl-dtb.hex, uboot.itb, atf, Linux Image). In the u-boot shell the command sf probe is now successful. When I try to continue the boot it fails because the FPGA image can not be loaded, but that's not the topic of this ticket.

    Did you replace the device tree and the linux image generated using the 25.1 flow?

    Yes, I've been careful to update all components in each test. When following the tutorials strictly, I used the dd command to overwrite the entire SD card. When I modified the .dts in the linux and u-boot projects, I've replaced the file socfpga_agilex5_axe5_eagle.dtb in the FAT partition, recompiled u-boot and regenerated the axe5_eagle_top_hps.sof and .jic file, and flashed the new axe5_eagle_top_hps.sof and .jic file via JTAG as described in the tutorials. When modifying the dts I did not replace the Linux image because it is unaffected by changes to the .dts file.

    I believe the Quartus Version you are using is still 24.3, but I think it is able to run with the 25.1 linux binaries.

    I don't understand what you are trying to say. The Quartus versions that I'm using are 24.2 and 25.1 (I've double checked). I don't have 24.3 installed.

    Did you make the same changes done to the uboot device tree with the linux device tree?

    Yes, I've modified the u-boot .dts and the linux .dts. As you can see from the log files, before changing the .dts there is no mention of an spi flash in the Linux boot and it boots just fine. Due to the change in the Linux .dts the kernel tries to probe the qspi flash and fails with the kernel panic that I've mentioned before.

    Are you able to reproduce this problem with the arrow 25.1 tutorial?

    Kind Regards,

    Eric Opitz

  • tehjingy_Altera's avatar
    tehjingy_Altera
    Icon for Regular Contributor rankRegular Contributor
    5 months ago

    Hi Eric


    Could you please share the latest boot log that you are facing?

    Did you replace the device tree and the linux image generated using the 25.1 flow?

    I believe the Quartus Version you are using is still 24.3, but I think it is able to run with the 25.1 linux binaries.

    Did you make the same changes done to the uboot device tree with the linux device tree?


    Regards

    Jingyang, Teh


  • EricOpitz's avatar
    EricOpitz
    Icon for New Contributor rankNew Contributor
    5 months ago

    Dear all,

    I've debugged a bit further. I noticed that the log message "QSPI: Reference clock at 500000 kHz" is missing in the build from version 25.1. The reason is that the following command fails (silently) in mailbox_s10.c:

    ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_QSPI_DIRECT, MBOX_CMD_DIRECT, 0, NULL, 0, (u32 *)&resp_buf_len, (u32 *)&resp_buf);
    I've tested with the SDM from version 24.2 by using the quartus_pfg from Quartus 24.2. Now, the SPL does print the log message "QSPI: Reference clock at 500000 kHz". In U-Boot proper console I can run sf_probe successfully. (Linux Kernel fails to boot, so I can't test QSPI probe from there. But that shouldn't be the topic of this ticket.)
    So I suspect that there is a problem in the 25.1 SDM.
    Kind Regards,
    Eric Opitz