Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC

From: Rob Landley
Date: Sun Aug 17 2025 - 14:46:18 EST

On 8/16/25 10:04, Andrew Lunn wrote:
On Sat, Aug 16, 2025 at 03:40:57PM +0200, Artur Rojek wrote:
On 2025-08-16 02:18, Andrew Lunn wrote:
Yes, it's an IC+ IP101ALF 10/100 Ethernet PHY [1]. It does have both
MDC
and MDIO pins connected, however I suspect that nothing really
configures it, and it simply runs on default register values (which
allow for valid operation in 100Mb/s mode, it seems). I doubt there is
another IP core to handle MDIO, as this SoC design is optimized for
minimal utilization of FPGA blocks. Does it make sense to you that a
MAC
could run without any access to an MDIO bus?

It can work like that. You will likely have problems if the link ever
negotiates 10Mbps or 100Mbps half duplex. You generally need to change
something in the MAC to support different speeds and duplex. Without
being able to talk to the PHY over MDIO you have no idea what it has
negotiated with the link peer.

Thanks for the explanation. I just confirmed that there is no activity
on the MDIO bus from board power on, up to the jcore_emac driver start
(and past it), so most likely this SoC design does not provide any
management interface between MAC and PHY. I guess once/if MDIO is
implemented, we can distinguish between IP core revision compatibles,
and properly switch between netif_carrier_*()/phylink logic.

How cut down of a SoC design is it?

The engineers focused on getting projects done for customers implemented what they actually needed, and had a todo list for potential future development that mostly hasn't come up yet.

(Most of the boards I worked on aren't actually using ethernet, but doing their own derived protocol that's electrically isolated and includes timing information in each packet. Same RJ45 jack, I think it even uses the same transceiver chip, but different protocol and signaling.)

Is there pinmux and each pin can
also be used for GPIO? Linux has software bit-banging MDIO, if you can
make the two pins be standard Linux GPIOs, and can configure them
correctly, i _think_ open drain on MDIO. It will be slow, but it
works, and it is pretty much for free.

MDIO itself is simple, just a big shift register:

My vague recollection is this SOC only implemented full duplex 100baseT because they didn't have any hardware lying around that _couldn't_ talk to that. So it never needed to downshift to talk to anything they tested it against, and there were plenty of desktop switches if we wound up needing an adapter in future for some reason. (1995 was a while ago even back then.)

The negotiation stuff was slated to be part of implementing gigabit ethernet, but 11 megabytes/second is actually pretty decent throughput for an individual endpoint so nothing's really needed it yet.

Turtle's FPGA couldn't easily do gigabit anyway: a spartan 6 can handle a 50mhz phy interface but 125mhz for gigabit is pushing it. That really wants something like Kintex (WAY more expensive, and runs quite hot). Even with the SOC in ASIC, a gigabit phy chip is still more expensive and consumes more power so needs a reason to use it.

There's been more interest in wifi and bluetooth, which you either get as its own chip or in a micro-sdio card because rolling your own implementation is a regulatory hellscape of spectrum compliance certifications in a zillion different jurisdictions. (Implementing it isn't that hard, getting permission to deploy it in a city is hard.) USB dongles are also available but consume WAY too much power.

Oh, a few years ago we did a USB 2.0 implementation in a Turtle HAT:

https://www.raspberrypi.com/news/introducing-raspberry-pi-hats/

And implemented a VHDL CDC-ECM ethernet device in the turtle SOC bitstream to test it out with, which did 40 megabytes/second sustained throughput no problem. (With not so much a "driver" as a quick and dirty userspace realtime program marshalling packets in and out of the hardware buffers to a TAP device. Both the USB and Ethernet PHY are basically parallel to serial converters so their outsides can clock way slower than the line speed of the protocol they transceive. The USB 2.0 one we used ran at 60mhz=3*5*2*2 and the ethernet needs 50mhz=5*5*2 so the voltage controlled oscillator could run at 3*5*5*2*2=300mhz and then get divided evenly down to drive both, and yes we had it run as a little gateway for testing.)

Alas, while CDC-EDM using the reference vendor:device IDs out of the USB standards document works fine out of the box on both Linux and MacOS, Windows refuses to recognize it because Microsoft demanded a five figure license fee from each hardware vendor to get a driver signed. (Lina Kahn didn't get around to them before the plutocrats plugged that hole in the pressure cooker.)

In an attempt to bypass the bastardry we changed the VHDL to do RNDIS instead (microsoft's own admittedly inferior version of CDC-EDM that they let you implement using an existing driver), and Greg KH went "my turn":

https://fosstodon.org/@kernellogger/109397395514594409

Which of course broke Android USB tethering.

*shrug* The 100baseT one works for us.

Rob

P.S. Way back when, we did slap quick wifi on an existing design once as a proof of concept using a three inch cat5 cable going to a $15 tiny single port wifi router from a store down the street in Akihabara. The 100baseT connection worked fine. Alas the tiny router couldn't _not_ NAT, and writing software to automatically navigate its built-in web page to associate with an access point was a rathole we didn't go down.

P.P.S. Oh, and we've connected boards over optical fiber using this transceiver chip. Those didn't call for mdio either, I'm not sure the VHDL changed at all, just board-level schematic changes. Technically that's 100baseF I believe.