Ethernet on Genesys 2 board

[asmi]

Hi,

I'm trying to get Xilinx's echo_server sample for lwIP to work on a board, however I get a message "WARNING: Not a Marvell or TI Ethernet PHY. Please verify the initialization sequence" on a console, followed by some nonsense like "auto-negotiated link speed: <some_random_value>". So it looks like lwIP stack shipped with Vivado doesn't support Realtek PHY which is used on that board. Do you guys have some sort of patch, or something to get this off the ground? 

I'm using Vivado 2019.1.

Thank you!

[asmi]

34 minutes ago, zygot said:

I generally avoid threads like this one because I don't use this flow... your problems being a good illustration as to why that is.

Here's my advice.

• Learn the basics of Ethernet
• Figure out how Ethernet PHY interfaces work. To start you only need to understand the one for your board which is RGMII
• Create your own Ethernet IP. Be sure to support the chip serial configuration MDIO interface.
• Support the minimal number of packet structures required to accomplish your goals.

This comment is ridiculous. I know IEEE 802.3 specification better than a lot of people, but this thread is not about that at all. My problem doesn't have anything to do with the fact that I know how Ethernet works. My problem is that Digilent chose to use PHY chip with NO public datasheet for this devboard AND did not provide any ready-to-use code to get it up and running. The way I see this one either picks a chip that has publicly accessible documentation, or it provides a code or module that allows users to utilize the chip without said documentation.

And finally - rolling out your own everything is a dead-end approach. New generations of people are taught previous generation's achievements and knowledge exactly so they could build on them, and not rediscover everything themselves over and over again. This is good if you have some interest or reason to do this (like doing this as a hobby, or existing solutions are not suitable for one reason or the other), but not as a general case. If I had to roll out my very own realtime video processing system I've done recently, it would take me years to complete instead of less than a week.

Also using preexisting IP is very good for HW checkout even if you plan to eventually replace it with your own code, as you at least get a known-good bitstream and software stack. If you use your own HW and SW at the same time, figuring out if stuff doesn't work because of HW or SW tends to be a massive PITA.

[boyerkg]

OvidiuD,

Please disregard my issue.  I had a flag set incorrectly in the bsp settings.  It was choosing the wrong lwip library.

Keith 

OvidiuD,

Please disregard my issue.  I had a flag set incorrectly in the bsp settings.  It was choosing the wrong lwip library.

Keith 

[boyerkg]

OvidiuD,

Thanks for the update on the Realtek repository.  I am getting the Warning that the PHY is not Marvell or TI, also.  I am also getting the link to be up then it drops down.  For a short time a ping will get through.  I downloaded your GIT repository and followed the bsp update, as you suggested, and I still get the error.

Any ideas.  I am on the nexys video board. 

Keith 

[asmi]

Thanks, I will look into it once I have some time. Even though I'm currently using 2019.2, I think I should be able to port these changes to code provided with Vitis.

[OvidiuD]

Hi, @asmi!

We have added support for Realtek PHYs in the 2019.1 lwip. 

You can find the updated repository here. You can download/clone it and add it in your project. Then:

1)From SDk's toolbar go to Xilinx, Repositories and add embeddedsw as a local repository as in the Step 1 screenshot attached(you can either add it with a relative path or a new absolute path).

2)In the project folder hierarchy go to echoserver, to embeddedsw and right click on it, click on Properties and in the C/C++ Build tab make sure the "Exclude resource from build" checkbox is checked(like in the Step 2 screenshot provided).

3)In the project folder hierarchy right click on echoserver_bsp then cllick on Re-Generate BSP resources

After going through these steps, your project should now be functional. 

Step 2:

Step 1:

[zygot]

59 minutes ago, OvidiuD said:

there is indeed a problem with the Vivado project in Vivado 2019.1

There is, in general, a problem with every Digilent demo if you try and use the source with a version of Vivado that is later than the one it was developed on. Partly this is due to Xilinx but other vendors have figured out how to release code that is more robust in the face of version change gremlins. Having SDK compile failures with source that is a few years out of date is almost acceptable but not for "hardware" logic designs. You can do better Digilent.

[OvidiuD]

Hello, @asmi

Having looked into it, it seems that there is indeed a problem with the Vivado project in Vivado 2019.1. While we are looking into it, one possible alternative is for you to use Vivado 2015.4. I've just tested the project on it and it works as described in the guide.

[zygot]

If anyone reading this is interested. I've been using Ethernet PHYs as general purpose data hoses for quite a few years now. I've posted in the Project Vault a version of a an Ethernet PHY tester meant to verify the post-route logic supporting the PHY to FPGA interface. It doesn't use any standard packet types though this is irrelevant to the problems being reported. Neither the tester nor any of the many DUT boards that I've used with it use the MDIO to configure the PHY. One of the DUT board PHY interface designs that  I've tested happens to be for the Geneysy2. It comes out of reset and auto-negotiates a perfectly good connection with the tester to receive and echo data back to the tester without error at data rates very near the maximum data rate possible. Based on a lot of experience with a lot of boards from at least 4 FPGA vendors the advice that I provided earlier is the advice that I'd give myself before I learned how to do it. Don't expect companies that offer solutions with no source code for a particular interface to assign an engineering team to fix your problem for your board. Be a zygot; don't be an asmi...

[zygot]

Hey, all that solved my problems. I hope that it worked out as well for you. Sometimes people aren't ready to evaluate what constitutes helpful advice is when it's been given; sometimes they're happier with poor advice that seems to be closer to the answer that they want. No problem. I never worry about what I can't control. I don't feel bad when my advice is rejected or ignored. Old people were young once... but not everyone improves with age.

[asmi]

18 minutes ago, zygot said:

You can always sign an NDA to get the information you want from vendors like Marvell or RealTek. Regardless, you aren't the first person needing to use one of their devices and if you do a bit of work you can find the information that you want. Obviously, we disagree on what your problem is.

The thing is - I don't really care what you think my problem is, as you obviously aren't even trying to be helpful.

18 minutes ago, zygot said:

No one rolls out "everything"... smart people figure out what battles to fight and what battles to avoid. As a dead-ender I have no problems using Ethernet with my Genesys2... how's that working out for you? It's just possible that someone who's survived 4 decades of technology might have opinions that aren't all dumb. Be we all make decisions for ourselves ( except when we are totally reliant on someone else's' work ). I don't whine about the consequences of my decisions.

I have my own opinion about the people who "survived 4 decades of technology" but apparently didn't figure out that making snide and offensive comments without even knowing the people they are talking to doesn't help anyone. And no, opinions of this kind of people are best ignored.

18 minutes ago, zygot said:

It is certainly possible to do a lot of things quickly using components that you can't ( or don't have the time ) to improve or let's you play i areas that you have no competency in. It's also possible to educate yourself to become competent in areas that you intend to explore and be very productive as well as innovative.If you believe that ignorance is a virtue, you are free to do so. Imaginations of productivity are, like beauty, in the mind of the beholder. 

I believe I can make my own decisions about what my interests are, what do I want to do myself, and when to employ someone else's solutions.

With that, and your obvious unwillingness to be helpful I kindly ask you to go do your rants elsewhere, as I'd like to receive a support that I've paid for from the vendor.

[zygot]

33 minutes ago, asmi said:

My problem is that Digilent chose to use PHY chip with NO public datasheet

You can always sign an NDA to get the information you want from vendors like Marvell or RealTek. Regardless, you aren't the first person needing to use one of their devices and if you do a bit of work you can find the information that you want. Obviously, we disagree on what your problem is.

33 minutes ago, asmi said:

And finally - rolling out your own everything is a dead-end approach.

No one rolls out "everything"... smart people figure out what battles to fight and what battles to avoid. As a dead-ender I have no problems using Ethernet with my Genesys2... how's that working out for you? It's just possible that someone who's survived 4 decades of technology might have opinions that aren't all dumb. Be we all make decisions for ourselves ( except when we are totally reliant on someone else's' work ). I don't whine about the consequences of my decisions.

 

33 minutes ago, asmi said:

provides a code or module that allows users to utilize the chip without said documentation.

Hey, this is a point that we agree on. Vendors of FPGA development boards should provide usable support for all of the interfaces on their boards, whether it's source code or some other means. After that the user should be responsible for conducting his own business. I've been suggesting this for years and you can see how successful I've been with that. In the end the customer is the only one who can choose a path for long term success,

It is certainly possible to do a lot of things quickly using components that you can't ( or don't have the time ) to improve or let's you play i areas that you have no competency in. It's also possible to educate yourself to become competent in areas that you intend to explore and be very productive as well as innovative.If you believe that ignorance is a virtue, you are free to do so. Imaginations of productivity are, like beauty, in the mind of the beholder. 

[zygot]

53 minutes ago, asmi said:

I've already tried setting 1G link speed, but it didn't work at all.

If your PHY gets initialized correctly from reset it's the PHY that auto-negotiates link speed and parameters with whatever is on the other end**. Ethernet PHY reset isn't as trivial as asserting a pin. Xilinx based FPGA development boards with a 1G Ethernet PHY, at least those that I've used,  come up properly configured to do 1G Ethernet. In my experience ( except for the Cyclone 10 LP dev board ) Intel based FPGA boards with 1G Ethernet PHYs come out of reset in an unusable state as an encouragement to use that dreaded canned IP Quartus is so anxious to provide.

** For most developer's not having bullet-proof IP what's on the other end should be another PHY on an FPGA micro-controller board in a walled-off environment. Switches, routers, networks are dangerous environment for even well-designed and security hardened clients... and visa versa. The internet has become a swamp filled with nasty predators so be careful and not a victim or enabler of bad actors. If your application doesn't need ( hopefully for all of use this is true, especially if you don't understand the ramifications of what you are doing ) internet connectivity then the Ethernet PHY is  a useful interface.

[zygot]

I generally avoid threads like this one because I don't use this flow... your problems being a good illustration as to why that is.

Here's my advice.

• Learn the basics of Ethernet
• Figure out how Ethernet PHY interfaces work. To start you only need to understand the one for your board which is RGMII
• Create your own Ethernet IP. Be sure to support the chip serial configuration MDIO interface.
• Support the minimal number of packet structures required to accomplish your goals.

You might be thinking that all of that is a waste of time when it appears that the tools vendor makes it all so easy. That's my point. It's better spending your time figuring out how to create your own HDL IP allowing you to control your own destiny rather than rely on canned and possibly source encrypted IP that others who have interests other than yours in mind. It's worse in the Intel universe. At least with my advice you will end up with code that can be used with anyone's board ( putting aside the various PHY data interface schemes ) and not worry about things that you have no control over. You aren't the only or first one wanting to do something useful with Ethernet FPGA applications so there is information out there to help with insight.

In your approach you get to live out the movie Ground Hog Day. I my approach you get to live your life. If you are a student with limited time I wish there were better options. If you don't have a class project due **soon** you at least have two options and no excuses.

 

[asmi]

3 hours ago, elodg said:

Indeed, the Realtek PHY support is only present in their PS MAC code. Since your issue PHY and not MAC-specificity, you can try porting the PHY init code to the AXI Ethernet MAC functions.

Yea I think that's the most sensible way to proceed. Will give it a try when I have some time.

3 hours ago, elodg said:

Apart from porting, you have other options as well: go back to the OOB demo version of the lwIP library or disable auto-negotiation and set a fixed link speed in BSP lwIP settings. Fixed link speed should work because I noticed that the auto-negotiated link speed query fails with the generic PHY init code. Let us know your results.

I've already tried setting 1G link speed, but it didn't work at all.

[elodg]

Indeed, the Realtek PHY support is only present in their PS MAC code. Since your issue PHY and not MAC-specificity, you can try porting the PHY init code to the AXI Ethernet MAC functions.

Apart from porting, you have other options as well: go back to the OOB demo version of the lwIP library or disable auto-negotiation and set a fixed link speed in BSP lwIP settings. Fixed link speed should work because I noticed that the auto-negotiated link speed query fails with the generic PHY init code. Let us know your results.

[asmi]

3 hours ago, elodg said:

Hello @asmi,

Please take a look at the latest commits to the embeddedsw repo, because there seems to be Realtek support now:

https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c

Thanks for the suggestion, but it looks like this file is only used for Zynq-based designs and its integrated MACs, there don't seem to be any relevant changes in xaxiemacif_physpeed.c file, which is the one used with AXI Ethernet Subsystem IP and Microblaze CPU.

[elodg]

Hello @asmi,

At least the OOB design works, which is a good starting point. The delay is due to how often the lwIP stack is polled in the demo among other tasks, and is expected.

PHY support is not in the scope of lwIP, so Xilinx contributes PHY and MAC-specific initialization code and re-packages it as a BSP library. Basic PHYs functionality is controlled by common registers, but advanced functionality is in manufacturer-specific registers. The library (very correctly) warns you that Marvell or TI-specific registers were not written, because the PHY is different.

Please take a look at the latest commits to the embeddedsw repo, because there seems to be Realtek support now:

https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c

The 2019.1 tag shows Realtek support present in the source code, so I expect it to be packaged with SDK. If it isn't, you can always take the latest source code, add it as a repository to SDK and it will appear as an option to add to BSP. BTW, this is also the route to go on, if you want to edit source code: make a copy of the library, rename it, add it as a repo and it will be pulled in during the Regenerate BSP Sources step of building the BSP.

[asmi]

4 minutes ago, vicentiu said:

Of course...   I overlooked the title.

What does the <some random value> look like?

Are you getting any other errors or just the one warning?

I tried many different things in time passed since I asked the question, and I've seen an advice on Xilinx forums to force lwIP into thinking this is a Marvel chip, but the best I was ever able to get was for the chip to successfully complete auto-negotiation at 1G, but it drops the link almost immediately, and so DHCP obviously fails. The link constantly goes up and down as I leave the code running. I tried pinging it, and every once in a while the link stays stable long enough for the ping to go through, but it's like 1 in 1000 chance so obviously not good enough for anything. 

The link is stable when OOB bitstream is loaded into FPGA (even though pings are like 50 ms between the board and computer on a same switch), which makes me think your software guys know a way to make it work, but so far I wasn't able to figure it out.

One BIG problem with this is that I was doing modifications in generated code (deep inside lwIP's code), and so these changes get lost every time I change anything in BSP settings (or in HW) with zero warnings or confirmations, so it was really annoying that I had to make changes multiple times only to lose them once again next time I'm not careful enough.

It also doesn't help that apparently the datasheet for the PHY chip isn't publicly available, so I had to invoke some wonders of Google-fu and scavenge quite dodgy sites to get something that looks even half-legit.

[vicentiu]

24 minutes ago, asmi said:

Genesys 2. It's right in the title.

Of course...   I overlooked the title.

What does the <some random value> look like?

Are you getting any other errors or just the one warning?

[asmi]

1 hour ago, vicentiu said:

What board are you working with?

Genesys 2. It's right in the title.

[vicentiu]

What board are you working with?