Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12419 Discussions

F.Y.I u-boot and TSE/SGDMA in Q9.1

Honored Contributor II

This is just F.Y.I 


I spent quite a time for debugging and noticed that the u-boot TSE driver with M88E1111 combination may not work properly in Q9.1 compiled H/W design. We compiled the 3C120(MMU Linux reference) design in Q9.1 and the u-boot stopped working. I also tried on the different custom board, and did not work either. 


We changed back to Q9.0 sp2, then both 3C120 board and our custom board can use the TSE/SGDMA in u-boot correctly. 

Where as, some one mentioned that Q9.1 compiled design is working on their board. So this may not always happens, but MAY happens. 


I do not think there are many people who is trying u-boot, but this is just an information. If you are having a touble in TSE and M88E1111 combination, try the Q9.0 rather than Q9.1 compiled H/W 



Bit more info: 

TSE & PHY will send and receive data, for the first iteration, and second iteration, the received data corrupts. I was using ping to test network, ARP send and receive was OK, then the TSE and PHY send out ICMP echo, and PC replyed for the ICMP, but the TSE was transmitting wrong data to Avalon-ST stream data. 

Since there seems to be a change in 9.1 for both TSE and SGDMA, I wouldn’t surprise the u-boot stop working... 


0 Kudos
2 Replies
Honored Contributor II


I'm experiencing exactly the same, with 10.1. However, TSE/SGDMA works fine with uClinux. Any clue or new info?
Honored Contributor II



I have had a similar problem working in 10.1. Found the sollution to be the RUN bit in the DMA controller control register (the receive SGDMA). it seems as though it is required to first clear the bit and then re-enable it when updating the descriptor memory to process the next message. In u-boot\drivers\net\altera_tse.c I had to modify alt_sgdma_do_async_transfer to the following (note that this is the async and not the sync function) 


static int alt_sgdma_do_async_transfer(volatile struct alt_sgdma_registers *dev, volatile struct alt_sgdma_descriptor *desc) { unsigned int status; int counter = 0; /* Wait for any pending transfers to complete */ alt_sgdma_print_desc(desc); status = dev->status; counter = 0; while (dev->status & ALT_SGDMA_STATUS_BUSY_MSK) { if (counter++ > ALT_TSE_SGDMA_BUSY_WATCHDOG_CNTR) break; } if (counter >= ALT_TSE_SGDMA_BUSY_WATCHDOG_CNTR) debug("Timeout waiting sgdma in do async!\n"); /* * Clear any (previous) status register information * that might occlude our error checking later. */ /* Get & clear status register contents */ dev->status = 0xFF; debug("rx sgdma status = 0x%x\n", status); dev->control &= ~ALT_SGDMA_CONTROL_RUN_MSK; //clear run bit /* Point the controller at the descriptor */ dev->next_descriptor_pointer = (unsigned int)desc & 0x1FFFFFFF; /* * Set up SGDMA controller to: * - Disable interrupt generation * - Run once a valid descriptor is written to controller * - Stop on an error with any particular descriptor */ dev->control = (ALT_SGDMA_CONTROL_RUN_MSK | ALT_SGDMA_CONTROL_STOP_DMA_ER_MSK); /* we really should check if the transfer completes properly */ return 0; } I can now tftp and ping from u-boot.