Cyclone V build flow questions (from Quartus to U-boot)

[BrianSune_Froum]

Dear Intel and All,

I am writing series of question and letting FAE or staff to settle.

Q1:

It is unclear that do previous version "hps_isw_handoff" can be reused on latest "https://github.com/altera-fpga/u-boot-socfpga". via the python script "cv_bsp_generator.py"

Q2: Based on Q1, do any format in xml is updated or changed and introduce possible information lost?

Q3: Experiment shows the HPS section via Q1 flow can generate a proper bootable result to distro on branch "socfpga_v2024.07". Where "socfpga_v2025.04" introduce immediate stuck on boot MMC1 message. Any bug and how to fix?

Q4: Based on Q1 to Q3, using the old build flow on 18.1+bsp-editor no issues are found to communicate between HPS2FPGA or FPGA2HPS, FPGA2SDRAM or SDRAM2FPGA etc.
Confirmed rbf is loaded and functioning. This is confirmed via HPS IIC to FPGA fabric. Where IIC devices are able to communicate under distro i2cdetect etc. 

However, using the cross-version flow the entire memory bridge h2f, f2h, lwh2f are all dead.
Which unable to communicate properly. How to fix this?

Q5: Under investigation, why the default dts on u-boot do not have 0xff200000 lwh2f bridge?

These are the question pool we are having trouble.

Please FAEs or stuffs response ASAP

Thank You

[BrianSune_Froum]

@JingyangTeh_Altera 

More info for the experiment.

Had also tried old and new argument on u-boot.

bridge enable
run bridge_enable_handoff

both still introduce stuck or crash during boot.

[BoonBengT_Altera]

Hi @BrianSune_Froum,

Thank you for posting in Intel community forum, hope all is well and apologies for the delayed in response.

Please find the below response from the question you have above.

Q1: It is unclear that do previous version "hps_isw_handoff" can be reused on latest "https://github.com/altera-fpga/u-boot-socfpga". via the python script "cv_bsp_generator.py"

BB: hps_isw_handoff contains HPS pin multiplexing and I/O settings generated during Quartus Prime compilation, which are necessary for creating the preloader image. Hence reusing it with a later u-boot-socfpga repository or cv_bsp_generator.py script is not recommended and highly likely to cause issues.

Q2: Based on Q1, do any format in xml is updated or changed and introduce possible information lost?

BB: the sources do not mention 'the XML schema for hps_isw_handoff has changed', they indicate that continuous updates and changes to the underlying HPS hardware configurations and peripheral definitions are frequent and significant

Q3: Experiment shows the HPS section via Q1 flow can generate a proper bootable result to distro on branch "socfpga_v2024.07". Where "socfpga_v2025.04" introduce immediate stuck on boot MMC1 message. Any bug and how to fix?

BB: Suspect the stuck is due to an incompatibility happens from changes in the Hard Processor System (HPS) hardware configuration and its software representation between these U-Boot versions. Would recommend to regenerating all hardware and soft component and ensure aligned to "socfpga_v2025.04" uboot branch. (Update development environment, regenerate HPS hardware handoff files, compile hardware design and rebuild emb software component)

Q4: Based on Q1 to Q3, using the old build flow on 18.1+bsp-editor no issues are found to communicate between HPS2FPGA or FPGA2HPS, FPGA2SDRAM or SDRAM2FPGA etc.

Confirmed rbf is loaded and functioning. This is confirmed via HPS IIC to FPGA fabric. Where IIC devices are able to communicate under distro i2cdetect etc. 

However, using the cross-version flow the entire memory bridge h2f, f2h, lwh2f are all dead.

Which unable to communicate properly. How to fix this?

BB: The HPS I2C to FPGA fabric communication works in the old flow, but the general bridges are dead in the cross-version flow suggests that the basic FPGA configuration might be loading correctly (since the I2C peripheral is in the FPGA domain and can communicate). 

But the HPS ability to properly configure its own IOs and internal interconnects for higher-bandwidth operations (like memory access via bridges or MMC communication) is failing due to the toolchain/U-Boot version mismatch

Q5: Under investigation, why the default dts on u-boot do not have 0xff200000 lwh2f bridge?

BB: The non-functionality of the 0xff200000 lwh2f bridge in a default uboot DTS is not likely a bug, but may be a configuration issue originated from specific hardware design, the boot software initialization sequence (preloader/U-Boot), and the precise device tree content being used.

Hope that clarify.

Best Wishes

BB

[BrianSune_Froum]

@BoonBengT_Altera 

Finally there are responses to the above question. Appreciated~

Would you mind to conclude the above backward compatibility?

Are old revision like 18.x, 19.x HPS handoffs are able to reuse on latest or more update build flow?

Thank you

[BrianSune_Froum]

@BoonBengT_Altera 

On top of the build flow.

After investigation reuse old handoff from 18.1 to 2024 via python is able to control lwh2f and sdram2fpga.

However, there is a major issue that cant understand.

on old workstation:

$ grep -r "PL330_DMA_BASE" .
./arch/arm/include/asm/arch-socfpga/pl330_csr.h:#define PL330_DMA_BASE_SECURE SOCFPGA_DMA_SECURE_ADDRESS
./arch/arm/include/asm/arch-socfpga/pl330_csr.h:#define PL330_DMA_BASE_NON_SECURE SOCFPGA_DMA_NON_SECURE_ADDRESS
./arch/arm/include/asm/arch-socfpga/pl330_csr.h:#define PL330_DMA_BASE PL330_DMA_BASE_SECURE
./drivers/dma/pl330.c: if (!(readl(PL330_DMA_BASE + DBGSTATUS) & DBG_BUSY))
./drivers/dma/pl330.c: writel(val, PL330_DMA_BASE + DBGINST0);
./drivers/dma/pl330.c: writel(val, PL330_DMA_BASE + DBGINST1);
./drivers/dma/pl330.c: writel(0, PL330_DMA_BASE + DBGCMD);
./drivers/dma/pl330.c: val = readl(PL330_DMA_BASE + DS) & 0xf;
./drivers/dma/pl330.c: val = readl(PL330_DMA_BASE + CS(channel_num)) & 0xf;
./drivers/dma/pl330.c: if (PL330_DMA_BASE == PL330_DMA_BASE_NON_SECURE)
./drivers/dma/pl330.c: printf("0x%08x\n", PL330_DMA_BASE);
./drivers/dma/pl330.c: if (PL330_DMA_BASE == PL330_DMA_BASE_NON_SECURE)
./drivers/dma/pl330.c: readl(PL330_DMA_BASE + FTC(pl330->channel_num)),
./drivers/dma/pl330.c: ((u32)readl(PL330_DMA_BASE + CPC(pl330->channel_num))
./drivers/dma/pl330.c: if (PL330_DMA_BASE == PL330_DMA_BASE_NON_SECURE)



However, new uboot do not have any pl330.

Please explain and help why this is the case.

Current situation is the DMA signal had no action returns.

Bests,

Brian

[BrianSune_Froum · Accepted solution]

@BoonBengT_Altera 

for uboot github 2024.07 all backward compile are working properly and no issue on control LWH2F H2F SDRAM2FPGA. DMA handshake req ack single.

DMA fix via:
community.intel.com/t5/Intel-SoC-FPGA-Embedded/Cyclone-V-H2F-DMA-is-dead/m-p/1714304#M3338

Case settled.

ENJOY~