Forum Discussion

Mikhail_a's avatar
Mikhail_a
Icon for Occasional Contributor rankOccasional Contributor
2 years ago

RVALID is high after reset on Agilex 7 M-series F2H bridge

Hello I work with Agilex 7 M-series device and I see a strange behavior of F2H bridge. I see that after deasserting f2h rst_n RVALID and BVALID signal go high, also I see some data coming from RDATA...
Configuration
EBERLAZARE_I_Intel's avatar
EBERLAZARE_I_Intel
Icon for Regular Contributor rankRegular Contributor
2 years ago

Hi,

Are you using this board?:

https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/agilex/agm039.html

May I know how you boot up the board, using SD card etc?

Can you explain briefly how you perform the reset, is it thourgh the signal tap?

Also, if you do a power cycle of the board does the signal also behave the same?

If you are using the above aforementioned board, we have the GSRD for it:

https://www.rocketboards.org/foswiki/Documentation/AgilexSoCGSRDDEVAGM039F

  • Mikhail_a's avatar
    Mikhail_a
    Icon for Occasional Contributor rankOccasional Contributor
    2 years ago

    Hi!

    You are right I use the exact same board.

    I used this GSRD from the rocketboards as a reference. But as I found out its u-boot doesn't enable FPGA-HPS bridges, so I have to build u-boot as described here https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderAgilex7 while using the same kernel and fsbl binary as in mentioned GSRD.

    I have a custom module that holds asserted reset for couple of minutes so I have time to enable signaltap and observe its deasserting. But even without this module I see that after ninit_done is asserted i have RVALID high. I see this issue every time I boot the board.

    • EBERLAZARE_I_Intel's avatar
      EBERLAZARE_I_Intel
      Icon for Regular Contributor rankRegular Contributor
      2 years ago

      Hi,

      Just want to check if you are also using the latest versions of the source code releases, U-boot = socfpga_v2023.10 etc..?

      Okay, so using the GHRD from Rocketboards, the FPGA configuration is done right before "starting the kernel", including enabling the FPGA bridges:

      Is it possible that you check again the signals behavior after booting to Linux as root in the signal tap? That would confirm that the bridge and FPGA enable and configured and the signal should behave as it should.

      If you still see otherwise, let us know.

      • Mikhail_a's avatar
        Mikhail_a
        Icon for Occasional Contributor rankOccasional Contributor
        2 years ago

        I use

        U-Boot SPL 2023.07-rc6 (Nov 20 2023 - 08:40:20 +0000) - got from GSRD
        and

        U-Boot 2023.10-31805-g69d5338be0-dirty - built by myself according to rocketboards guide

        and boot log looks like this:


        CPU: Intel FPGA SoCFPGA Platform (ARMv8 64bit Cortex-A53)
        Model: SoCFPGA Agilex SoCDK
        DRAM: 2 GiB
        Core: 28 devices, 23 uclasses, devicetree: separate
        WDT: Started watchdog@ffd00200 with servicing every 1000ms (10s timeout)
        MMC: dwmmc0@ff808000: 0
        Loading Environment from FAT... OK
        In: serial0@ffc02000
        Out: serial0@ffc02000
        Err: serial0@ffc02000
        Net: eth0: ethernet@ff800000
        Hit any key to stop autoboot: 0
        10739712 bytes read in 499 ms (20.5 MiB/s)
        FPGA not ready. Bridge reset aborted!
        ...........FPGA reconfiguration OK!
        38816256 bytes read in 1817 ms (20.4 MiB/s)
        32237 bytes read in 5 ms (6.1 MiB/s)
        RSU: Firmware or flash content not supporting RSU
        RSU: Firmware or flash content not supporting RSU
        RSU: Firmware or flash content not supporting RSU
        RSU: Firmware or flash content not supporting RSU
        ## Flattened Device Tree blob at 08000000
        Booting using the fdt blob at 0x8000000
        Working FDT set to 8000000
        Loading Device Tree to 000000007eafb000, end 000000007eb05dec ... OK
        Working FDT set to 7eafb000

        Starting kernel ...

        Deasserting all peripheral resets
        [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]