Message-ID: <d4f291e3-9d4f-4724-91de-742f9ace5b86@landley.net>
Date: Sun, 17 Aug 2025 13:09:41 -0500
From: Rob Landley <rob@...dley.net>
To: Andrew Lunn <andrew@...n.ch>, Artur Rojek <contact@...ur-rojek.eu>
Cc: Jeff Dionne <jeff@...esemi.io>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC

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.

Powered by blists - more mailing lists