User Profile

Archer_Altera

Occasional Contributor

Joined 5 years ago

24 Posts6 LikesLikes received2 Solutions

View All Badges

User Widgets

Contributions

Re: XDP on agilex3
Hi Torstein18, Stmmac does not implement a full zero‑copy TX path, even on recent kernels. The “few packets then stops” behavior you see is a classic symptom of that gap. mas-bandwidth/af_xdp/001 is a pure AF_XDP userspace TX loop. On stmmac, what typically happens: First packets go out (driver does a fallback copy or partial DMA) TX completion path never frees UMEM frames correctly TX ring fills up Kernel stops accepting new descriptors sendto() succeeds briefly, then silently stalls This is not a userspace bug in your example. For AF_XDP ZC TX, the driver must implement: ndo_xsk_wakeup ZC‑capable TX rings Correct UMEM lifetime handling What does work reliably is XDP_TX / XDP_REDIRECT from an XDP program, not AF_XDP userspace TX ZC. You may consider implementing below flow. FPGA → shared memory → XDP program → XDP_TX Key points: FPGA writes packet buffers into shared memory (ensure cache coherency/IO-MMU mapping is correct). CPU does NOT copy payload XDP program simply sets headers and returns XDP_TX No AF_XDP socket involved Hope this is helpful. Archer_Altera
24 days ago Place SoC System
3Views
1like
0Comments
Re: Reading S25FL256S OTP region via QSPI Indirect Transfer on Cyclone V HPS — data comes back incorrect
Hi miscellaneous-mice, Thanks for your update. Looks like you have found the root cause and tested with the code you shared, is this solution good enough for your project to move on? Archer_Altera
2 months ago Place SoC System
47Views
0likes
1Comment
Re: Reading S25FL256S OTP region via QSPI Indirect Transfer on Cyclone V HPS — data comes back incorrect
Hi miscellaneous-mice, Please try following 4 items on your side and see anyone can solve the issue. Item 1: Manually Increase Dummy Cycle Configuration Although the datasheet specifies 8 dummy clocks, the Cyclone V QSPI controller in indirect mode sometimes requires an additional cycle to compensate for internal delays. Try setting dummy cycles to 16 (equivalent to 2 bytes) to check alignment: read_cfg.dummy_cycles = 16; // Attempt to increase dummy cycles Forces the controller to wait longer before data arrival, ensuring the internal FIFO pointer points to the first valid data. Item 2: Verify and Force Address Length Configuration You set .addr_size = 2 (representing 3 bytes). Ensure the register is actually written after calling alt_qspi_device_size_config_set. More importantly, explicitly reset certain controller states before switching back to Quad mode or before each Indirect read. Attempt to execute a small STIG read (e.g., reading the status register) before performing an indirect read to “wake up” or synchronize the controller to Single SPI mode: // Perform a small STIG operation to synchronize status before indirect read uint8_t dummy_sr; alt_qspi_stig_rd_cmd(0x05, 0, 1, &dummy_sr, timeout); // Read Status Register // Then perform indirect read alt_qspi_read(dst, src, size); Item 3: Correcting Post-Read Offset (Software Workaround) If you confirm the hardware behavior is reading an extra 0xFF (this has appeared in errata for some Flash controllers, where Indirect Read always includes a leading dummy byte), you can handle it at the software level: Allocate 1 extra byte when allocating the buffer. After reading, shift the pointer back by 1 byte, or skip the first byte during copying. // Temporary buffer, allocate 1 extra byte uint8_t temp_buf[size + 1]; // Execute read operation alt_qspi_read(temp_buf, src, size + 1); // Note: Length must match here, or read only size while ignoring the first byte // Data actually starts at temp_buf[1] memcpy(dst, temp_buf + 1, size); Verification method: If you observe temp_buf[0] always being 0xFF while temp_buf[1] contains correct data like 97, this confirms a fixed 1-byte leading offset in the controller. Item 4: Check alignment of INDRDCNT and INDRDSTADDR Cyclone V QSPI data register accesses sometimes require 4-byte alignment. If your dst pointer is not 4-byte aligned, or size is not a multiple of 4, the memcpy inside the HAL library may fail, or misalignment may occur when the hardware FIFO pops. Ensure the dst pointer is 4-byte aligned (((uint32_t)dst % 4) == 0). If size is small, try rounding up to a multiple of 4 for reads, then truncating to valid data. Archer_Altera
2 months ago Place SoC System
2Views
0likes
3Comments
Re: SDRAM calibration failed.
Hi qwitza Thanks for uploading the error log. The function test_load_patterns(0, ALL) returned 170, but the expected value was 255. This indicates that the test pattern written to DDR (typically 0xFF) was read back as 0xAA (i.e., 170). Since 0xAA is 0b10101010 and 0xFF is 0b11111111, this suggests that certain DQ bits are stuck at 0. Since only two boards have this issue, it is most likely hardware issue such as DQ pin connectivity issues (open circuit, short circuit, or poor soldering). Hope this is helpful. Archer_Altera
6 months ago Place SoC System
85Views
0likes
0Comments
Re: SDRAM calibration failed.
Hello qwitza, Can you let me know which uboot version you prefer to use? I will try to find the solution on it. Regards, Archer_Altera
6 months ago Place SoC System
142Views
0likes
0Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, You may use link below as an entry to find more Nios V related document. https://www.altera.com/design/guidance/nios-v-developer Hope this is helpful. Archer_Altera
6 months ago Place Nios® System
24Views
1like
0Comments
Re: SDRAM calibration failed.
Hi @qwita, Is it convenient for your design to upgrade uboot version to 2024.07 or later? This will be helpful for me to investigate this case and support you. It will be benefit for you to get support in later development process. If it is not convenient, I will try to help you with uboot 2020.01 version. For both ways, please give me some time to run on hardware to find the correct method. By the way, latest uboot, linux guidance document for cyclone V device is posted on link below. https://altera-fpga.github.io/rel-25.1.1/embedded-designs/cyclone-v/sx/soc/boot-examples/ug-linux-boot-cve-soc/ Regards, Archer_Altera
6 months ago Place SoC System
149Views
0likes
0Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, Only qip file is needed. Regards, Archer_Altera
6 months ago Place Nios® System
44Views
1like
5Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, Rather than Adding QSYS into project, please add QIP into the project. From 25.1std, the tool supports QIP only due to a change in Quartus compiler. The tool also prompts with message below. You may find a qip file located in the same folder of qsys system top level hdl file under project directory liking this. Hope this is helpful. Archer_Altera
6 months ago Place Nios® System
107Views
1like
7Comments
Re: ERROR building simple NIOSV Compact project
Hi Barry, I can reproduce the issue you met on my side. This needs time for us to find the root cause. I will let you know when there is progress about this. Regards, Archer_Altera
6 months ago Place Nios® System
88Views
1like
9Comments