Basic Questions About Ethernet

[n00b1024]

Hello,

I'm working on setting up the Ethernet module in a VF6, and have a few questions about how to do so. I'm pretty new to Ethernet, so some of these questions are fairly general.

1. How do I write data into the payload? In the manual, 42.4.6 (rev4) states that "writing to MMFR triggers a management frame transaction to the PHY device." Is that what I need to use? If MMFR is used for writing data into the payload, that register gives me 16 bits (only two octets) to work with. Should I instead write data directly to the Tx data buffer, whose location is specified in the transmit buffer descriptors (Table 42-191). If so, what would I use MMFR for?

2. What's EBD? There's a reference to it in Table 42-191, where it says that (referring to the bit that is set to generate interrupt flags)

"This field is valid regardless of the L [last frame] field and must be the same for all EBD for a given frame." I assumed that EBD meant Ethernet Buffer Descriptors, but this seems to imply that there are multiple buffers (and hence multiple INT bits) for a given frame. Does a payload contain more than one set of transmit buffer descriptors?

3. What does the Wrap transmit buffer descriptor do? The datasheet says that "0: The next buffer descriptor is found in the consecutive location, 1: The next buffer descriptor is found at the location defined in ETDSR [ENET_TDSR]," but I don't entirely understand what that means.

Thanks for reading!

[naoumgitnik]

Dear n00b1024,

The company policy is that our applications software engineers develop code (called BSP - Board Support Platform) running on the hardware platform board (Vybrid Tower Board in this case), which contains all the information required to develop software for our customers. Some of them copy fragments from it, some, based on our code and comments, analyze the algorithm and develop their own code. All this is done to "answer in advance" all the possible future specific questions similar to those you are asking.

Please take a look at the below links for the 2 supported OSs:

MQX: http://www.freescale.com/webapp/sps/site/overview.jsp?code=MQXSWDW

Linux: https://linuxlink.timesys.com/register/freescale.

Sincerelty yours, Naoum Gitnik.

[hmijail]

Naoum,

Copying parts of software sounds certainly risky when developing a commercial product.

You are saying that we are supposed to reverse-engineer and reimplement (or even copy) code that has been published under the GPL (for the Linux case at least). Does Freescale provide any kind of waiver or guidance so we can use Freescale's driver code without licensing problems?

What about MQX, what are the licensing conditions? Can we just take what we need from the driver code?

[naoumgitnik]

Dear Horacio,

·         The published generic code has been developed by Freescale to be used by the customers for free, without any special licensing procedure, just with a simple online "click-through" approach, of course with some disclaimers (of the "on your own risk" kind, which is quite common in the industry). We have never had such a question from the field in the past, and I am a bit curious what triggered it...

·         Plus, we always try to comment the code well to not force our customers into any reverse-engineering.

Sincerely, Naoum Gitnik.

[hmijail]

Naoum,

You referred us to Timesys for the BSPs. This is what Timesys has to say about the subject:

"You can avoid violating such licenses by following a simple rule: Never integrate any source code that is released under the GPL into your proprietary source code. Linux device drivers for proprietary hardware are the most common development effort that triggers redistribution concerns. If directly compiled into the Linux kernel (which is released under the GPL V2 license), the source code for those device drivers must be released under the GPL."

https://linuxlink.timesys.com/docs/wiki/embedded_linux_development#Intellectual-Property-and-Embedde...

About "derived works" they say:

"Beware of derived works, e.g., adding open source code into your application (polluted code)"

https://linuxlink.timesys.com/3/FAQ#obligations

I hope to be wrong, but to me it looks like copying code from Linux, and probably even taking too much inspiration from it, is a recipe for problems if one intends to distribute the product while keeping the source private.

And the only code I have been able to find in Timesys' website are full Linux kernels and/or multi-megabyte patches affecting tens or hundreds of kernel files, among which the Vybrid MAC-NET core support is intermixed with an existing family of MAC controllers, and needs other infrastructure from the kernel, like the PHY Abstraction Layer, DeviceTrees (for pin multiplexing, clocks, etc), and on and on. So if one only wants to get the minimal, specific code needed to support the Vybrid MAC-NET core, there is certainly a lot of reverse engineering to do.

Certainly this doesn't look like a substitute for the bring-up guides that Freescale published for other uCs, like Kinetis. Or am I missing something?

About MQX's BSP, the situation looks slightly better, if only because it seems to have less infrastructure to cut through. But what about the license?

Any clarification would be welcome.

[Ragan_Dunham]

Horatio,

Please download the latest version of MQX to review the license.  You are able to use it in proprietary implementations but you will need to study the license yourself as well.

Thanks,

Ragan

[hmijail]

Thank you for your answer, Ragan.

Out of curiosity, is there any explanation for why the code is published with these licenses? If the goal is to allow direct usage, study and reimplementation, why not use some BSD license, or even publish the BSPs directly for any of the BSD variants?

[Ragan_Dunham]

Freescale chooses this license for our proprietary software.  The specifics of why this versus that I cannot answer.  Thanks.

[karina_valencia]

Ragan_Dunham /  GerryKwiecinski can you review and  comment about  previous reply from Horacio?