New Contributor
Regular ContributorHi,
May I know which version of Quartus, Uboot version and Kernel version you are using for this testing?
If using the GHRD, are you seeing the same issue?
Do you have the screenshot of the output/registers status? I may need sometime to look into this issue.
New ContributorQuartus Pro 20.4.0 and U-BOOT 2020.07-08704.
Doing the work with DS + JTAG and we only rely on U-BOOT to set-up the clocking and pin muxing.
We are not using GHRD but our own driver: the driver is OK on the Cyclone V, Arria 5 & Arria 10 (I am aware the Synopsis EMAC version is different between these and Agilex). To reproduce the problem, any working EMAC driver for the Agilex likely does the same as U-BOOT, which is to blindly write to the dmagrp_transmit_poll_demand register. That's even if the DMA is still going on. Wrap all instances of these with a "IF" the TU bit of the dmagrp_status register having is 1, and the TX will not work (or only one packet will get out). Look at the TX descriptor chain and you will see new descriptors are parked, the DMA is in standby but not reporting it got into standby not having a descriptor to send out. Write to dmagrp_transmit_poll_demand register and these parked packets will go out and once they are all out the TU bit will still not be set to 1.
New ContributorI forgot to specify when the TU bit is set (within the "IF") it is cleared by writing 0x4 to the dmagrp_status register because the bit is not self-clearing.
Regular ContributorHi,
This seems like an uncommon issue, I shall check with our internal team on this issue. Could it possible that you would check with our GHRD if the issue is the same?
