Re: [PATCH 2/3] dt-bindings: net: Add support for J-Core EMAC

[Rob Landley <rob@landley.net>]

On 8/18/25 03:07, Krzysztof Kozlowski wrote:
> On 18/08/2025 08:43, Geert Uytterhoeven wrote:
>>>>
>>>> You need SoC-based compatibles. And then also rename the file to match
>>>> it.
>>>
>>> Given how the top-most compatible of the bindings [1] of the board I am
>>> using has "jcore,j2-soc", this driver should probably go with
>>> "jcore,j2-emac".
>>>
>>> But as this is an FPGA design, I don't know how widespread the use is
>>> across other jcore derived SoCs (if any?).
>>> I will wait for Jeff (who's design this is) to clarify on that.
>>>
>>> PS. Too bad we already have other IP cores following the old pattern:
>>>
>>>> $ grep -r "compatible = \"jcore," bindings/ | grep -v "emac"
>>>> bindings/timer/jcore,pit.yaml:        compatible = "jcore,pit";
>>>> bindings/spi/jcore,spi.txt:   compatible = "jcore,spi2";
>>>> bindings/interrupt-controller/jcore,aic.yaml:        compatible =
>>>> "jcore,aic2";
>>
>> I would go with "jcore,emac", as it is already in use.
> 
> git grep jcore,emac
> 
> Gives me zero?

Ethernet support wasn't part of the original kernel submission, in part 
because we hadn't created the turtle board yet (and _still_ don't have a 
consumer retail arm to get them out into the world in less than triple 
digit lot sizes) and the off the shelf FPGA board we were pointing the 
open source community at circa 2016 (Numato Mimas V2) didn't include 
ethernet.

(Also, our internal driver had half an unfinished IEEE-1588 
implementation in it, which we kept meaning to clean out for public 
consumption. We took a different approach to time synchronization but 
had never produced a clean driver for external use until Artur decided 
to do one, which was very nice of him.)

>> If an incompatible version comes up, it should use a different
>> (versioned?) compatible value.
> 
> Versions are allowed if they follow some documented and known vendor SoC
> versioning scheme. Is this the case here?

This ethernet implementation hasn't significantly changed in 10 years.

Whenever we've needed something else we've done different I/O devices 
that weren't ethernet. (Even the USB 2.0 "ethernet" isn't technically 
ethernet, it made our board act as a USB dongle that showed up as an 
ethernet device to the computer it was plugged into so we could exchange 
data. No actual ethernetting really occurred, it's kind a like calling 
slip/ppp or virtio-net an ethernet interface.)

In theory gigabit phy would be a successor to this, A) no idea if they 
would share any code on the VHDL _or_ C side, B) that kind of phy 
requires 125mhz clock speed which is less cost effective in FPGA, 
especially now that AMD bought xilinx and doubled the prices. (We've 
stuck with LPDDR2 for similar reasons, although that's on the shorter 
term todo list to support. I mean yeah we _could_ use various FPGAs' 
builtin DDR3 library but we don't because we only want to use stuff we 
can implement ourselves in ASIC, and we need to not just test the state 
machine (minimum jedec clock speed 300mhz: kintex or vertex territory) 
but also commission the analog part of the circuit which is 
process-specific so you have to pick a fab to have them drawn for if 
you're avoiding NDAs and per-chip royalties for other people's black box 
libraries.

(Oh, and the higher up the FPGA stack you go the less likely yosys' open 
source FPGA tools are to work right, and the more NDA-clingy the closed 
source tools get, which is kind of annoying for a mostly non-US 
development team. (Lots of testing for $50 FPGAs, far less for $700 
FPGAs plus the more lawsuit-happy the vendors get about their crown 
jewels.) Gowin is trying but those suckers SUCK DOWN power, the ones 
I've seen are Lattice clones not Xilinx clones (ecp5 exists if we want 
_bigger_ lattice, the question is _faster_), and going that direction is 
really just a different kind of ecosystem lock-in...)

tl;dr: the 100baseT engine works fine for its niche, we've had no reason 
to fiddle with it.

> This is some sort of SoC, right? So it should have actual SoC name?

https://github.com/j-core/jcore-soc

Internally we have branches for various projects, which are named after 
the project not the base platform. It's "j2" because it's the dual 
processor version. J1 is what we use on ICE-40:

https://github.com/j-core/jcore-j1-ghdl

They're _mostly_ the same but the j2 SOC build has a whole automatic bus 
generator thing that pulls in dependencies (it's written in cloture and 
java) and the broken out j1 builds with just the 01 and 02 stages of the 
https://github.com/j-core/openlane-vhdl-build open source 
toolflow/toolchain. (There's a todo item to reorganize the repositories 
so j1 becomes a git submodule of j2 which would naturally keep them in 
sync, but it was all originally done in mercurial and needs a bit more 
massaging. Plus recently we've done a j1 fork removing the hardware 
multiplier and did a software multiplier toolchain, which hasn't made it 
over to the J2 side yet because it really needs a better configure 
mechanism (VHDL generics sure but what _selects_ them...) which REALLY 
says we need to rewrite the makefiles entirely... it's on the todo list.)

Rob

P.S. We haven't been pushing to github much since Microsoft bought it. 
I'm trying to convince Jeff to look at codeberg but he's hung up on the 
gitea->forgejo fork...