ProFromDover_Altera
Occasional ContributorJoined 5 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: NIOS II "Verify failed" for on-chip memory 128k
Can you share a screen shot of your Nios II instruction master and data master address map? I'm interested in the "Address Map" tab in platform designer showing the full address map of the connected peripherals to each of the instruction and data masters on the Nios II. I don't quite understand how the BOOT RAM fits into your system here. Are you configuring your BSP for this application that you're trying to download with the "Allow code at reset" option enabled in the BSP editor? Or are you just trying to compile the program that would load and execute in your RAM at 0x20000? Can you provide a screen shot of your BSP Linker Script tap that show how the software sections are mapping into your memory regions? The error that you're getting basically means that the code downloader attempted to write the data from your program into the target memory and then it read it back to verify the contents and the read back does not match what it wrote in originally. This can be caused by various hardware or BSP misconfigurations which is why I'd like to see the screen shots that I requested above. If you'd like to simply test your hardware configuration, you could create some test images that you can download to the target where you fill a few test files with 8K, 32K, 64K and 128K of data for instance. That could give you confidence that your hardware is configured and working properly and point towards a BSP configuration issue. Or it could identify that your hardware is not operating correctly. Here's an AI description on how to create a Random ELF file that you could use to load the Nios II memory with nios2-download: To create a Nios II ELF file with a specific 128KB loadable section filled with random data at address 0x20000, you need to generate the raw random binary data, link it using a custom linker script, and compile it using the Nios II toolchain. 1. Generate the Random Data Binary First, create a raw binary file containing exactly 128KB of random data. bash dd if=/dev/urandom of=random_data.bin bs=1k count=128 Use code with caution. 2. Create the Custom Linker Script Create a text file named linker.ld. This script defines the target memory address and forces the random data into a loadable section. linker MEMORY { /* Define the target memory region */ random_mem : ORIGIN = 0x20000, LENGTH = 128K } SECTIONS { /* Create a loadable section named .random_section */ .random_section : { KEEP(*(.data)) } > random_mem } Use code with caution. 3. Convert the Binary to an Object File Use the Nios II binary utility tool to wrap your raw binary into an object file (.o). This flags the data so the linker can recognize it. bash nios2-elf-objcopy -I binary -O elf32-nios2 \ --rename-section .data=.random_section \ random_data.bin random_data.o Use code with caution. 4. Link into the Final ELF File Link the object file using your custom linker script to output the final ELF executable. bash nios2-elf-ld -T linker.ld random_data.o -o random_data.elf Use code with caution. 5. Verify the ELF File You can verify that the section was created correctly, has the right size, and is marked as loadable (LOAD). bash nios2-elf-objdump -h random_data.elf Use code with caution. Look for .random_section in the output. It should show a size of 00020000 (128KB), a VMA/LMA of 00020000, and the flags CONTENTS, ALLOC, LOAD, DATA.0Views0likes1CommentRe: JTAG_UART stuck in printf
With this flow, you're getting the default BSP configuration, which depending on the complexity of your system it may not be making the choices that you expect. Can you share the settings.bsp file that is created by this flow? The system.h and alt_sys_init.c would be useful as well.70Views0likes1CommentRe: JTAG_UART stuck in printf
If you can programmatically print characters out the JTAG UART by directing your program to write to the JTAG UART interface, that would tend to indicate that your hardware is probably configured alright. At least you do know what the base address is of the JTAG UART peripheral, but this doesn't prove that you have the IRQ from the JTAG UART connected to the Nios V processor. I think you are correct to focus on the BSP configuration and see if there's anything out of order in that area that could explain what's going on when you printf. Fundamentally you need to have the JTAG UART configured as the peripheral that should connect to the stdin, stdout and stderr streams from the HAL library. And then depending on whether you selected reduced device drivers or regular drivers, there may be a need to have the IRQ from the JTAG UART connected in your Platform Designer system and properly represented in the BSP, or the system.h header. Can you share the sequence that you use to create your BSP? It sounds like you may just be running niosv-bsp from the command line. If you could share some details about that, and also share your system.h and alt_sys_init.c that gets generated from the BSP generation flow, that may help shed some light on what's going on. If you can share the settings.bsp file that may be useful as well.49Views0likes0CommentsRe: Arria 10 SoC FPGA
From what you've described, it sounds like you're basic device presents itself as a USB serial device based on an FTDI chipset, correct? You said "the kernel does identify the device as a USB 2.0 but doesn't assign any device". This makes me wonder if your Linux kernel has been compiled with the appropriate drivers or not. I believe the ftdi_sio driver is what is generally used to support an FTDI chipset for USB serial operation, do you know if that is present in your kernel? I believe at a minimum you need the CONFIG_USB_SERIAL and CONFIG_USB_SERIAL_FTDI_SIO kernel configs enabled in your kernel. If the ftdi_sio driver is compiled in as a loadable module, you might check to ensure that it is installed on your root filesystem properly. I don't believe you should require any custom udev or mdev rules to enable a basic USB serial connection. Are you running a defauilt binary image of the GSRD example on your Arria 10 SoC dev kit? Or are you running a custom software configuration? The latest GSRD binary image released on releases.rocketboards.org does not appear to have CONFIG_USB_SERIAL enabled by default: https://releases.rocketboards.org/2025.10/gsrd/a10_gsrd/sdimage.tar.gz The u-boot-spl banner prints with this build date: U-Boot SPL 2025.07 (Sep 25 2025 - 01:10:31 +0000) The u-boot banner prints with this build date: U-Boot 2025.07 (Sep 25 2025 - 01:10:31 +0000)socfpga_arria10 Once in Linux you can see this kernel build date: root@arria10:~# uname -a Linux arria10 6.12.33-altera-g96a033bc584c #1 SMP Thu Sep 25 06:05:32 UTC 2025 armv7l GNU/Linux Then if you inspect the kernel configuration you see that CONFIG_USB_SERIAL is not enabled by default: root@arria10:~# gunzip -c /proc/config.gz | grep CONFIG_USB_SERIAL # CONFIG_USB_SERIAL is not set If this is the environment that you are using, you will need to recompile your kernel to enable this functionality.41Views1like0CommentsRe: Cache coherency on Agilex 5 when booting secondary cores without ATF
I am not aware of any guides or resources that you could reference to do something like this. I suspect that this type of use case is documented in the generic ATF documents and an AI chatbot may be able to suggest patterns that could be deployed for something like this.428Views0likes0CommentsRe: Cache coherency on Agilex 5 when booting secondary cores without ATF
I would suggest that you boot through the default bootloaders into your application so you can leverage all of the default configurations that they apply to the HPS for you, rather than trying to accurately replicate that in your own custom boot sequence. The FSBL which can be the ATF bl2 code but is typically the u-boot-spl code, will configure the HPS in general, ensuring that the HPS handoff data is correctly applied to the HPS, which gets the clocking and HPS IO and HPS EMIF all configured as the HPS was configured to operate in the Quartus project, and then it configures all the secure registers in the firewalls and things like that to get the HPS in the operational state that you expect. Then it passes control to the ATF bl31 code which finishes configuring the DSU and CPU cluster for proper default behavior. You would need to replicate all of that functionality in your own custom boot sequence to bring things up to a similar state. If you need to use group 0 GIC interrupts, then you'll need to configure those from a secure state. Your realistic options are secure EL3 or secure EL1. To do this in S-EL3 state with the ATF code present, you'd be better served to apply your own customizations into the ATF code base and interact with your NS-EL2 application. To do this in S-EL1 state with the ATF code present, you'd need to start your secondary core and it's application to enter S-EL1 state and then operate from there.699Views0likes1CommentRe: Cache coherency on Agilex 5 when booting secondary cores without ATF
I have used the the PSCI_CPU_ON infrastructure provided by the ATF bl31 environment quite a bit to start secondary cores and I find that they are always coherent within the CPU cluster with no additional effort. I typically boot though the u-boot-spl bootloader into u-boot proper through the ATF flow so bl31 is left behind in DRAM as the secure monitor which handles the PSCI_CPU_ON requests. If you could follow a flow like this, I believe this would be much simpler flow to get working the way that you wish. If you must do this is a purely bare metal fashion, I suspect that the configuration you are missing is not in the CCU section of the HPS but more likely in the DSU and the snoop filter that manages choerency within the quad core cluster and L3 cache system. Unfortunately I don't have any examples that demonstrate that raw flow, and I don't know if the configurations that you would be missing are in the u-boot-spl or bl31 parts of the boot loader flow that I typically use.685Views0likes1CommentRe: GTS PMA/FEC Direct set-up
Have you looked at section 6.12 of the GTS Transceiver PHY User Guide: Agilex™ 5 FPGAs and SoCs? It states: The example design runs an external loopback test by default, with the loopback_mode parameter set to 0. To perform an internal loopback test you must set the loopback_mode to 1 in the parameter.tcl file, located at: <design_example_dir>/hwtest/src/ If needed, update the JTAG port ID by modifying the jtag_port_id parameter in the same file. The default value is 0.1.2KViews1like1CommentRe: GTS PMA/FEC Direct set-up
I'm not sure this question is posted into the proper forum, it seems more like an FPGA IP forum topic. Where are the hex addresses defined from in the /src folder? The example designs generated for the GTS IP generally connect one JTAG Avalon Master Bridge to the subordinate/slave interface of the IP core alone. So the address map that the system console scripts are accessing are defined by the GTS IP core itself. This is a rather complex core with multiple functions define a different base addresses within the IP core itself but you should be able to correlate the references that you see in the system-console scripts to the various register maps defined in the user guide. Is there a standard way to go about integrating this example into a larger project? This is a standalone design example that gets generated to evaluate the IP in this standalone configuration. There is no standard way to integrate this example into a larger project. Fundamentally, once you understand how the IP core operates in the mode that you're interested in using, you would then determine what makes sense from an implementation perspective to fit this functionality into your larger project. But since there are many different applications that the GTS can be integrated into, there is no standard way to do this. It's possible that you may find other system level example designs that would demonstrate a specific implementation of the GTS in that use case which may provide a better example of how it could be implemented in that specific use case.1.4KViews1like3CommentsRe: NIOS V on-die temperature sensor for Stratix 10
I would recommend that you look at the latest version of the Mailbox Client IPs User Guide located here: https://www.intel.com/content/www/us/en/docs/programmable/683290/25-1/mailbox-client-s-user-guide.html Section 1.5 describes the Avalon MM interface that can be exposed on that IP core rather than the Avalon ST interface that you are referring to. Connecting a Nios V to the Avalon MM interface would be much simpler and more straight forward. Section 1.11 describes the Nios V HAL software support that can be used to interact with the Mailbox Client IP core.2KViews0likes1Comment