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

Hi @BrianSune_Froum,

Thanks for sharing on overcoming the issues and good to know that issues has been overcome, with no further clarification on this thread, it will be transitioned to community support for further help on doubts in this thread.

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.

Thank you for the questions and as always pleasure having you here.

Best Wishes

BB

@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

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

@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.