Accessing raw RMII buffers / disabling MAC functionality

P

phasedarray

New member
Hi all,

I asked this on the NXP community forums and received no reply, and since I'm prototyping on (and might even do small production run with) a Teensy 4.1 I thought to ask here in case someone has some idea.

At work we have a proprietary communication system that uses off the shelf ethernet physical layer. Our existing FPGA-based solution interfaces over RMII to a standard ethernet PHY, but everything above the physical layer is custom. The PHY handles 4b:5b, and clock+data recovery for us, and our FPGA handles the rest of the encoding/decoding. However this FPGA is going EOL and our FPGA engineer has long since retired. I've therefore been thinking of trying to access this raw RMII data and process it myself on an RT1060 or similar, given that we were already looking at the RT series for embedded UI.

I've been looking through the RT reference manuals have come up with 3 potential options:

  1. Edit the Ethernet RCR (Receive Control Register), TCR (Transmit Control Register) and Receive and Transmit Accelerator Function Config Registers (RACC and TACC) to disable all of the MAC functions and operate use the MAC FIFOs as if we were working with normal Ethernet.
  2. Set up DMA to copy the ENET TX and RX buffers from/to somewhere else for processing and ignore the rest of the MAC.
  3. Use FlexIO to emulate RMII, which would also allow us to do some masking/sync word detection more efficiently.

I am quite unfamiliar with Ethernet above the physical layer and I am not sure that in scenario 1 whether we can sufficiently disable functionality of the MAC that the MAC's FIFOs exactly match what is transmitted to / received from the PHY and that nothing will be padded/discarded/checksummed etc.

With scenario 2 I am still not sure if it's possible to directly access the RMII TX / RX buffers and if they are unmodified by the MAC when the MAC is enabled, and when the MAC is disabled I don't know if the RMII interface continues to run.

I am most comfortable with the idea of using 3 because I have used FlexIO before, but it is also potentially a lot more work if we can indeed just disable / ignore the MAC, and it uses up FlexIO buffers which we also want to use for communication with another proprietary device.

FWIW I found some discussions on this forum about sending raw Ethernet frames, but as far as I understand from the code (for instance https://github.com/ssilverman/QNEthernet.git) the headers/checksum etc are still handled on the MAC/library. What I need to do is access the raw deserialized PHY RMII data and handle the decoding myself.

Many thanks in advance

Rob
 
Can you give us a link to the NXP conversation? Just curious to see what their people say.

Not sure if it will help, but here is the earliest low-level code from before NativeEthernet and QNEthernet.

https://github.com/PaulStoffregen/teensy41_ethernet/blob/master/teensy41_ethernet.ino

You could turn on promiscuous mode, so all frames are received. You can get all bytes of the frame received to the buffers, but you probably can't customize how the hardware decides what is a frame. The hardware works pretty much like most other ethernet, you create a list of buffer descriptors which have pointers to your actual buffers. As the hardware receives frames, it writes the actual frame to your buffer and updates the buffer descriptor, clearing a flag to let you know it's finished receiving a frame into that descriptor's buffer.

This program has minimum parsing of incoming packets, pretty much so it can reply to ARP and ICMP (ping). You'd probably just delete the incoming() function if you're using your own layer 2 protocol.
 
Hi Paul, thanks for the fast reply.

The post on the NXP site is here, but so far I've not had a response: https://community.nxp.com/t5/i-MX-R...w-RMII-buffers-to-from-PHY/m-p/1623316#M24299

My understanding of promiscuous mode was that it forwards all frames regardless of the recipient. The problem is we don't receive 'frames' that look anything like ethernet; there's no preamble, no delimiter and no inter-frame pause at the end. It's a packed stream of samples delineated by a sync word, so my concern was that the hardware would never write anything to any buffers that I give it.

I will take a look through the low level code on Monday and see if I can understand it better. I only have one T4.1 with me here but I plan to get another and try to set up a simple 'not-Ethernet' loopback to try and pass a test stream back and forth.

If I can get that running step 2 would be to make up a basic PCB with our usual PHY connected to the T4's second RMII port and test it with that. Since we actually use 100Base-FX over copper (CDDI more or less) for transport the T4.1's PHY's MLT3 output wouldn't work with our existing products.
 
PaulStoffregen said:
I'm pretty sure the concept of ethernet frames is deeply baked into the hardware.
Click to expand...

I had a suspicion that might be the case. Thanks, this at least points me more in the direction of FlexIO as my next line of enquiry. Will go over it with a fresh set of eyes come Monday morning.

Rob
 
You must log in or register to reply here.
Back
Top