TSE MAC and Marvell 88E1111

[Altera_Forum]

I'm having trouble to bring up the TSE MAC to Ethernet interface on the Stratix II GX PCIe board. I was able to instantiate a triple speed Ethernet MAC and build logic around it. The loopback at the GMII interface seems work fine. However, I'm not able to send any packet out via the on board Marvell 88E1111 Ethernet transceiver. I suspect I need to program the registers in it via the MDIO. Is there a register map or data sheet of the 88E1111? Or is there anything else I'm missing? 

 Thanks.

[Altera_Forum]

--- Quote Start ---   As for the empty data packet, it can come from the CPU data cache. Try to flush the data cache before sending the packet, or use the alt_remap_uncached() function to modify your pointer to the memory buffer that you fill in.  --- Quote End ---    I tried to use uncashed but the result is the same. 8 Frame 69 (126 bytes on wire, 126 bytes captured) Arrival Time: Nov 24, 2009 13:50:20.538005000 Frame Number: 69 Frame Length: 126 bytes capture Length: 126 bytes 0 Ethernet II, src: 00:07:ab:f0:Od:ba (00:07:ab:f0:Od:ba), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) S Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) 0 = IG bit: individual address (unicast) 0 = LG bit: Globally unique address (factory default) Ј В mds Header(unknown(0)/unknown(0)) В mds Header ...0 0000 0000 0000 = Packet Len: 0 0000 0000 00.. = Dst index: 0x0000 00 0000 0000 = src index: 0x0000 0000 0000 0000 = VSAN: 0 В mds Trailer eof: unknown (0) CRC: 0x00000000Where can I have a look of configuring of SGDMA and how to бфлу a descriptor for daata memory to transmit?

[Altera_Forum]

Is the packet size correct? 

To build a descriptor, you can use the functions defined in altera_avalon_sgdma.h. The alt_avalon_sgdma_construct_mem_to_stream_desc() can build the descriptor for you. It is well described in the SGDMA datasheet.  If it isn't a cache problem, it could be because the SGDMA isn't reading the memory at the correct address. But at least it seems to try to read 126 bytes.

[Altera_Forum]

The size of packet is correct. I also use the standard functions from SGDMA. 

Unfortunatelly I don't have any workable example with correct configured registers of TSE and SGDMA, maybe there is special bit I should set to make it work =(  I try to make it using the user guide of TSE and SGDMA with it examples. here is the example of my code for Marvell 88e1111, if anybody would have a need of half worked example or anybody would look through the text of program and will find any mistakes or bugs it would be greatfull.

[Altera_Forum]

I can see a few problems in tse_mac_raw_sendM. 

First you don't bypass the cache when writing the packet contents. Second, in the "recopy to buf2" loop, you are reading the contents back using IORD_8DIRECT, whereas you filled it the [] operator. The second method uses the cache, but the first one bypasses it, so you may read back completely different data. Third, you don't use the ActualData pointer in the SGDMA descriptor.  I would first create two uncached pointers: char *uncached_pkt = alt_remap_uncached ((volatile void*) pkt, 256); char *uncached_buf2 = alt_remap_uncached ((volatile void*) buf2, 1560); Then use the uncached versions to access the data:  uncached_pkt=0xCC; uncached_pkt=0xCC; for(k=2;k<254;k++){ uncached_pkt=0xA5; } uncached_pkt=0xEE; uncached_pkt=0xEE;  for(i=0;i<length;i++) { uncached_buf2 = uncached_pkt; } ActualData = (unsigned int*)buf2;(by the way, I'm not sure buf2 will be properly 32-bit aligned this way...) Then to remove bit 31 before building the descriptor, you need to call remap_cached, not remap_uncached:  ActualData = (unsigned int*)alt_remap_cached ((volatile void*) ActualData, 256); And finally build the descriptor with ActualData:  alt_avalon_sgdma_construct_mem_to_stream_desc( (alt_sgdma_descriptor *) desc, // descriptor I want to work with (alt_sgdma_descriptor *) desc,// pointer to "next" (alt_u32 *)ActualData, // starting read address (length), //# bytes 1, // don't read from constant address 1, // generate sop 1, // generate endofpacket signal 0); // atlantic channel (don't know/don't care: set to 0)  I hope this helps

[Altera_Forum]

unfortunatelly after the alt_avalon_sgdma_check_descriptor_status(desc) desc_stat = 119  

Owned_by_HW = 1 and i get not free of errors descritor # define EINPROGRESS 119 /* Connection already in progress */

[Altera_Forum]

Try to use a separate descriptor for the "next" argument in alt_avalon_sgdma_construct_mem_to_stream_desc. 

Maybe something like alt_avalon_sgdma_construct_mem_to_stream_desc( (alt_sgdma_descriptor *) desc, // descriptor I want to work with ((alt_sgdma_descriptor *) desc)+1,// pointer to "next" (alt_u32 *)ActualData, // starting read address (length), //# bytes 1, // don't read from constant address 1, // generate sop 1, // generate endofpacket signal 0); // atlantic channel (don't know/don't care: set to 0)I'm not sure about what happens if you make the descriptor point to itself as "next". If that's not it, I don't have any other idea... I never had this problem with the SGDMA.

[Altera_Forum]

You are supposed to get that status until the transfer has been done. Try to call alt_avalon_sgdma_do_async_transfer() or alt_avalon_sgdma_do_sync_transfer() and check the status again.

[Altera_Forum]

didn't notice there is a TSE topic here. 

 http://www.alteraforum.com/forum/showthread.php?t=19915

[Altera_Forum]

Could anyone help me with my weird 88e1111 tx problem? 

http://www.alteraforum.com/forum/showthread.php?t=20140

[Altera_Forum]

Good day. 

 I have a problem with NicheStack and a PHY. I am using the 3sl150 Stratix III based devkit. As I am a beginner, I am using NIOS II standard design that comes with the board. As I tried to launch the Simple Socket Server (SSS) application, it could not allocate the PHY (the board's PHY is Marvell 88E1111 that is supported by the driver by default, as it is written in the documentation) and came up with the error:   [tse_mac_init] INFO : TSE MAC 0 found at address 0x00001400 ERROR : MAC Group[0] - No PHY connected! ERROR : PHY[0.0] - No PHY connected! Speed = 100, Duplex = Full OK, x=401, CMD_CONFIG=0x00000000  The design uses Triple Speed Ethernet in RGMII mode for networking.  There are no other MAC interfaces (like lan91c111) in the design.  What can be wrong? 

[Altera_Forum]

Hi Foreshadow, 

First of all look at your comand config register = 0x00000000 it can't be so in full duplex and 100 Mbit. Then the main error - no PHY, maybe there are some errors with physical connection of PHY. have a look in closed topics to this, there some pictures of pinouts, it should help you. 

[Altera_Forum]

--- Quote Start ---  Hi Foreshadow, First of all look at your comand config register = 0x00000000 it can't be so in full duplex and 100 Mbit. Then the main error - no PHY, maybe there are some errors with physical connection of PHY. have a look in closed topics to this, there some pictures of pinouts, it should help you.   --- Quote End ---     Thank you for your answer. I have found the solution here:   http://www.alteraforum.com/forum/showthread.php?p=86569   И.. Кстати, из Ваших постов подчерпнул несколько весьма полезных замечаний, которые удалось применить в своем дизайне.. Спасибо))) А проблема была в том, что именно на этой отладочной плате (3sl150) неудачно подключен чип Marvell - нужно перезагружать вручную...

[Altera_Forum]

hi all 

if you need, here is an interessant paper have fun and please, i need help for something, maybe some can help me on this forum : "Need help : implement Gigabit Ethernet" thanks in advance

[Altera_Forum]

I'm sorry but I had to edit your message and remove your attachment. 

The datasheet is under an NDA and Marvell forbids anyone to reproduce it without their authorisation. I find it stupid but it's their rules ;)

[Altera_Forum]

ho i didn't know that 

ty for the advice

[Altera_Forum]

can you please answer this simple question Marvel Alaska 88e1111 is software programmable? or hardware programmable only by changing low high states on its pin?

[Altera_Forum]

--- Quote Start ---  can you please answer this simple question Marvel Alaska 88e1111 is software programmable? or hardware programmable only by changing low high states on its pin?  --- Quote End ---    Hello,  Marvell 88E1111 is a software programmable.  Good Luck

[Altera_Forum]

Ok 

I will try to give you an advice

[Altera_Forum]

--- Quote Start ---  The TSE is able to communicate with up to two PHYs through MDIO. You need first to set up the MDIO address of the PHY, with one of those calls:IOWR_ALTERA_TSEMAC_MDIO_ADDR0(base,data) IOWR_ALTERA_TSEMAC_MDIO_ADDR1(base,data)Obviously the first line sets the MDIO address for the PHY number 0 and the second one sets the MDIO address for the PHY number 1. base is tse_mac_base, as you guessed, and data is the MDIO address.  Then you can access the register with one of those calls:IORD_ALTERA_TSEMAC_MDIO(base, mdio, reg_num) IOWR_ALTERA_TSEMAC_MDIO(base, mdio, reg_num, data)The first line reads, the second writes. base is again tse_mac_base, mdio is the PHY number (0 or 1, depending on the call you used to set up the MDIO address), reg_num the MDIO register number, and data is the value to write.  --- Quote End ---    Hi,  I'd like to connect one TSE with two Marvell PHYs:  1- Are the above Macros are all that we need? 2- How we are going to connect the MDIO & MDC to both PHY devices?  Your prompt response is highly appreciated.  Thanks & Regards.

[Altera_Forum]

the MDIO is a shared bus. You can have a signgle MDC and a single MDIO pin on the FPGA, connected to both MDC and MDIO pins on the PHY chips. 

If they are already connected separately, then you'll have to write a little logic to merge them into a single bus inside the FPGA. The MDC is output only so you can just duplicate the signal. The MDIO is bidirectionnal though, so you need a bit more. When used as an output you can duplicate it to both PHYs too, and when used as an input, just do an AND between the two inputs from the PHYs before feeding it to the TSE.

[Altera_Forum]

--- Quote Start ---  the MDIO is a shared bus. You can have a signgle MDC and a single MDIO pin on the FPGA, connected to both MDC and MDIO pins on the PHY chips. If they are already connected separately, then you'll have to write a little logic to merge them into a single bus inside the FPGA. The MDC is output only so you can just duplicate the signal. The MDIO is bidirectionnal though, so you need a bit more. When used as an output you can duplicate it to both PHYs too, and when used as an input, just do an AND between the two inputs from the PHYs before feeding it to the TSE.  --- Quote End ---     Hi,  Thank you very much for your prompt & valuable reply.  We would like to confirm the connection between the TSE MAC & the 2 PHYs, so kindly check the attached image.  I thought that we may need OR not AND between the inputs from the two PHYs, so kindly explain.  Best Regards.