JitLoonL_Altera
Occasional ContributorJoined 1 year ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: HPS ip configuration in platform designer for uart0 enabling in arria 10 soc
Hi Essen, Great job getting the .axf generated! To answer your question directly: No, ARM DS and its license are not mandatory for generating the .bin file or for running the application on your board. ARM DS is primarily used as an interactive JTAG debugger. If your goal is just to package and run your bare-metal firmware, the free tools already included in the SoC EDS Command Shell are completely sufficient. Here is the high-level alternative method to get your code running without ARM DS: 1. File Conversion: You can convert your .axf file into a raw .bin file using the standard GNU utilities (like objcopy) provided within the SoC EDS Command Shell. 2. U-Boot Image Creation: Once you have the .bin, you will use the shell's built-in image tools to wrap it with a header so the board's bootloader (U-Boot) can recognize and execute it. 3. SD Card Execution: Finally, you just copy that newly created image file onto the FAT32 partition of a bootable SD card. When you power on the Arria 10 board, you can interrupt the boot sequence via your UART terminal and instruct U-Boot to load and run your application directly from the SD card. Let us know if you would like the specific documentation or guidance on the exact utilities needed for those steps.9Views0likes0CommentsRe: HPS ip configuration in platform designer for uart0 enabling in arria 10 soc
Hi Essen , If your Platform Designer configuration has UART0 enabled and routed to the dedicated HPS I/O pins, you are on the right track for the hardware side. Ensure you have generated the system and compiled the hardware project to get the .sof file and the handoff files. For the software side, developing a bare-metal application on Windows without involving Linux is fully supported using the SoC EDS Embedded Command Shell and the Altera HWLIBs. Here is the step-by-step workflow to get your "Hello World" running over UART0: 1. The Bare-Metal C Application Reference You do not need to write this from scratch. You can find the official bare-metal "Hello World" examples in the Altera Open Source GitHub repository here: https://github.com/altera-opensource/intel-socfpga-hwlib/tree/master/examples/A10 Note: Since you mentioned using the Linaro Bare-Metal Toolchain, make sure you look at the Altera-SoCFPGA-HelloWorld-Baremetal-GNU example, rather than the ARMCC version, so your Makefile aligns with the GCC compiler. In the main.c of that example, the core logic relies on #include "alt_uart.h" and #include "alt_clock_manager.h". It handles initializing the clock, initializing the UART0 instance, setting the baud rate (115200), and using alt_printf() or alt_uart_write() to output the string. 2. Building/Compiling with the Linaro Toolchain To build this in Windows: Open the SoC EDS Embedded Command Shell (run Embedded_Command_Shell.bat from your SoC EDS installation folder). This environment automatically sets up the paths for the Linaro arm-none-eabi-gcc compiler. Navigate to your downloaded Altera-SoCFPGA-HelloWorld-Baremetal-GNU directory. Run the make command. This will compile your .c files, link them against the HWLIBs, and generate an .axf (or .elf) executable file. 3. Generating Boot Files (For SD Card/Flash Boot) If you intend to boot this application standalone from hardware (instead of debugging via JTAG): Use the bsp-editor to generate the U-Boot SPL (Preloader) from your Quartus hardware handoff folder. Compile the Preloader using the Command Shell. Use mkimage (available in the EDS shell) to wrap your compiled binary with a U-Boot header, creating an .img or .scr script that U-Boot can execute to jump to your bare-metal entry point. 4. Loading and Running on the Target Device (JTAG Approach) For initial bare-metal development, it is much faster to load and run the code directly into RAM via JTAG using ARM Development Studio (ARM DS), which is bundled with SoC EDS. Connect your Intel FPGA Download Cable (USB Blaster) to the Arria 10 board. Open ARM DS and create a new Debug Configuration. Select the target as Arria 10 SoC and connect via the USB Blaster. Point the debugger to your compiled .axf file. ARM DS will load the executable directly into the HPS RAM via JTAG and halt at main(). Try pulling down the GNU example from the GitHub repository and compiling it in the SoC EDS shell. Let us know if you hit any roadblocks during the build phase.0Views0likes1CommentRe: Nios V/m JTAG run‑control HALT fails — Debug Module healthy, hart never halts
Hi relsaar_design Your isolation here is spot on. The DMI evidence (abstractcs = 0x08000002 and dmstatus = 0x00400cc3) definitively proves that the JTAG chain, SLD Hub, and the RISC-V Debug Module (DM) are completely healthy and authenticated. The symptom you are describing (dmstatus remaining running, haltreq timing out) is the classic hallmark of an Avalon bus hang. In the RISC-V architecture, entering Debug Mode via an external debug request (haltreq) is a non-maskable trap, but the hart must be able to cleanly retire its current instruction or flush its pipeline to take that trap and jump to the debug ROM. If the Nios V hart comes out of reset and immediately issues an instruction fetch to the Avalon-MM fabric, and the slave never completes the transaction (e.g., holding waitrequest high indefinitely, or failing to assert readdatavalid), the processor pipeline stalls permanently. A frozen hart physically cannot process the haltreq from the DM, resulting in the exact timeout and OpenOCD aborts you are seeing. (The riscv-openocd project tracks this precise behavior under Issue #195: a blocked memory bus prevents the debugger from halting the hart during examine). Direct Answers to Your Questions Q1. Known Erratum? There is no publicized, unresolved erratum for Quartus Pro 26.1 stating the IP fundamentally ignores haltreq post-enumeration. The issue is almost certainly an architectural response to a stalled memory interface rather than a bug in the intel_niosv_m halt logic itself. Q2. Required Connections/Parameters? Yes. The Reset Vector and Exception Vector must point to fully initialized, mapped, and responsive memory. Furthermore, Nios V is strictly a 32-bit master. If your memory subsystem (e.g., OCRAM or external flash) is configured for 16-bit or 8-bit data widths without an Avalon-MM Pipeline Bridge to handle the width adaptation, the interconnect fabric can silently hang. This is the exact root cause behind Intel KB 000096654, which you referenced; the width mismatch causes a bus hang, leading directly to Ashling IDE timeouts. Q3. Arria 10 JTAG/SLD Interactions? There are no documented fundamental incompatibilities here. Your DMI reads confirm the SLD hub is flawless. The failure boundary is strictly isolated to the Hart-to-Avalon interface, not the JTAG-to-SLD path. Recommended Troubleshooting Steps To prove the bus is hanging immediately after ndmreset is released, I recommend the following: Signal Tap the Avalon Masters Drop a Signal Tap instance onto the Nios V Instruction Master and Data Master interfaces. Trigger on the rising edge of read or write. You will likely see the master assert a read for the reset vector, and the fabric either never responds with readdatavalid or holds waitrequest high indefinitely. Verify Reset Vector Target Double-check the memory component assigned to the Reset Vector in Platform Designer. Ensure it is not being held in reset by a different clock/reset domain, and that its driving clock is actively toggling and locked. Audit Data Widths Check all memory slaves connected to the Nios V instruction and data masters. If any are not 32-bit, insert an Avalon-MM Pipeline Bridge between the Nios V and the slave to ensure proper fabric translation.0Views0likes0CommentsRe: USING SIGNAL TAP TO MONOTOR AVALON_BUS WITH NIOS DESIGN
Hi aiedb , This usually comes down to a few common issues when using SignalTap on Avalon-MM in a Nios II / Platform Designer system: 1. Wrong signal location (very common) Make sure you’re tapping the signals at the correct hierarchy. Avalon signals go through the interconnect, so if you tap near the IP but not the actual connected interface, you may see nothing. 2. Signal optimization Quartus might optimize away unused signals. Try setting the signals or module to preserve/keep, or enable SignalTap node preservation during compilation. 3. Clock mismatch Double check that SignalTap is clocked by the same clock domain as the Avalon interface to the on-chip flash. If the clock is wrong, triggers won’t fire. 4. Trigger condition too strict A rising edge on write may not trigger as expected (due to pipelining or waitrequest). Try: Trigger on write == 1 Or (write && chipselect) Or even immediate trigger just to confirm activity 5. Transaction may not be happening Confirm your software is actually performing the write to CFM0. You can temporarily add a simple debug (e.g. GPIO toggle) to correlate. 6. Capture depth Increase SignalTap buffer depth—short Avalon transactions can be easy to miss. 7. Recompile properly Make sure you did a full recompile after adding SignalTap and programmed the correct .sof.6Views0likes0CommentsRe: Agilex 5 HPS TEE
Hi rdrr, Just to consolidate the responses in this thread. Agilex 5 HPS supports Arm TrustZone at the hardware level. The current released TF-A platform flow loads BL31 (EL3 runtime) and BL33 (non-secure OS). BL32 is not enabled by default in the reference software. While there is no publicly released OP-TEE design example today, the platform hardware and TF-A architecture are capable of supporting a TEE. OP-TEE enablement is an area of active internal work. Potential use cases under evaluation include secure key access and secure services. A design example is being considered for a second-half-2026 timeframe, subject to roadmap prioritization. Feedback on concrete use cases such as RPMB-backed secure storage is welcome and helps guide direction. JL49Views0likes0CommentsRe: Unique ID registers in Cyclone V
Hi, A number of identification mechanisms exist on Cyclone V devices, but none of them function as a dedicated, per-device hardware serial number on the HPS side in the same way some other SoCs provide. What is available depends on which part of the chip you are accessing. JTAG IDCODE Cyclone V devices include a 32-bit IEEE 1149.1 IDCODE, and the documentation lists the values for each family member. This code identifies the device type, variant, and revision, which can be useful for checking what device is present in a chain. However, the IDCODE follows a fixed format (version + part number + manufacturer), so it does not differentiate one physical device from another of the same model. System Manager registers The HPS System Manager exposes some identification fields such as silicon revision, but the available fields generally describe the device class rather than provide a unique per-unit identifier. The fields tend to be constant across all devices of the same family/stepping. FPGA-side Unique ID There is also a Unique Chip ID feature available in the FPGA fabric through specific Intel IP. This can be used to retrieve a value that is tied to the FPGA die. If HPS access is required, it can be bridged into the HPS through lightweight AXI/Avalon interfaces. Whether this meets the use-case depends on the system architecture. Board-level alternatives Some systems instead rely on identifiers stored outside the SoC—for example: eMMC CID registers QSPI/NAND flash locations provisioned during manufacturing External EEPROM with a programmed serial number These methods provide stable per-unit identification when a silicon-level ID is not exposed.26Views1like0CommentsRe: enable bridge crashes Linux
Hi @dpeng , Looking at your DT, the bridges are currently disabled, which explains why changing the clock in Linux DT alone didn’t help. For your setup: fpga_bridge@ff400000 (LW HPS-to-FPGA) is the one you likely need for HPS → FPGA communication. You should enable it in your DT like this: &fpga_bridge0 { status = "okay"; clocks = <&h2f_user2_clk>; /* match Platform Designer */ resets = <0x06 0x61>; /* keep original reset lines */ }; fpga-bridge@ffc25080 (FPGA-to-SDRAM) only needs enabling if your design specifically requires FPGA → SDRAM access. Remember, the DT in Barebox should match the Platform Designer settings. Enabling the bridge and assigning the correct clock there is necessary before Linux can use it. After this change, check the live DT in Linux - status should now be okay and the bridge should be functional.3.2KViews0likes1CommentRe: FPGA-HPS DDR contention on Agilex5 SoC while running Linux: efficient data exchange strategies
Hi @ppp2 , Yeah, you’re right to be concerned. On Agilex 5 SoCs, if your FPGA is streaming a lot of data straight into DDR, it can hog the memory interconnect and slow down Linux or even cause memory allocations to stall. I’ve run into similar issues before. A few things that usually help: Throttle the FPGA traffic via HPS-FPGA bridges: Use the bridges’ QoS settings or limit burst sizes on the FPGA side so the HPS always gets guaranteed memory bandwidth. This prevents the FPGA from starving the CPU. DMA + double buffers: Don’t let userspace hit the memory directly. Stream data via FPGA-to-HPS DMA using ping-pong or circular buffers. Userspace programs can then safely read from these buffers. Kernel mediation: A small kernel driver exposing these buffers via mmap or a character device keeps everything safe and avoids contention on DDR. Sync with userspace: Use interrupts, eventfd, or similar signaling mechanisms to notify userspace when new data is ready, rather than busy-waiting, which can also hammer the memory bus. The key idea is to control FPGA memory access through the bridges and have a structured path for Linux/userspace to consume the data efficiently without blocking the HPS.408Views1like0CommentsRe: enable bridge crashes Linux
Hi @dpeng It looks like the board freeze occurs when the bridge drivers (lwhps2fpga/ hps2fpga) attempt to enable the bridges. Since FPGA programming works but enabling the bridges causes a hang, this is likely due to hardware configuration or base address mismatch between your Terasic boards and the Enclustra SA2 module. A few suggestions: Check bridge base addresses in your device tree against the Enclustra SA2 memory map; the addresses may differ from the DE0/ADC-SoC boards. Verify preloader / handoff settings – the bridges must be properly configured and clocked before enabling them. Enable one bridge at a time to isolate which one causes the hang. Reference Enclustra BSP,compare their provided socfpga.dtsi or device tree overlays for correct bridge configuration. Most hangs in regmap_write() indicate access to an unclocked or unmapped peripheral region. Once the bridge base addresses and clocks match your module, the overlay should work as expected. If possible, please share the live DT nodes for fpga_bridge0 and fpga_bridge1 after boot but before applying the overlay; that can help pinpoint the issue.3.3KViews0likes1CommentRe: Unable to access rocketboards.org
Thank you for raising this. We are aware that www.rocketboards.org is currently unavailable. Our team is looking into the issue, and we will provide an update once the site is back online. In the meantime, if you need access to GSRD resources, you may find some of the materials mirrored on the Intel FPGA GitHub repositories. We apologize for the inconvenience and appreciate your patience while we work to restore access.611Views0likes0Comments