GL-MT5000 (Brume 3) upstream OpenWrt support

Router
83

@jamster - you're right. Worth clarifying:

That Brume3’s have already shipped running the rtl8366ub_mdio.ko,which is declared GPL. GL has no other option than to provide the complete corresponding source for the binary including any Realtek SDK code compiled into it. Whether the GL dev that wrote this driver was unaware of how GPL works or just taking a shortcut doesn’t matter now. In the end, GL built on GPL code for the .ko and shipped product with it. NDA has no weight here. They need to publish this yesterday - there’s no other “out” for this one.

The part I mention about the register map would be a go-forward strategy for GL (the way they probably should have done it already, but too late now). In the future they could write a driver in the same style of the existing rtl8366rb/rtl8366s drivers, using direct register access with zero vendor SDK and remove RT's code from the picture entirely. This would prevent future entanglement, AND in this case would have prevented the existing bugs they introduced b/c the upstream code already had it right.

I don’t think there’s a vendor dispute over this.. it’s simply a matter of them honoring the GPL license obligations by publishing the source so they’re respecting OpenWRT project’s code & copyright they built on.

@bruce - when can we expect GL to answer on this?

2 Likes
84

To put all this in plain language for anyone trying to follow.

GL could have kept RT's SDK code out of the .ko driver entirely: build on the OpenWrt base, write their own register-level calls to the chip, and publish the whole thing back as GPL source. They just would have needed either the register map from RT, or to reverse-engineer the registers with probes in order to write the calls.

Instead, someone took the path of least resistance: they took the GPL base code, dropped in RT's SDK to do the register work instead of writing their own, and wired a glue layer between them - all compiled into one .ko, which (because it's built on GPL code) makes the whole module GPL. Less effort up front, but a serious mistake as you can't compile NDA'd code into a GPL-derived module and still meet the GPL's duty to publish complete source. GL should have obtained RT’s permission to include the code before using it. Not a bell that can be un-rung now though. These .ko's have already shipped so GL has no choice but to publish (and work out the aftermath with RT on their own).

Ironically, the bugs they introduced are direct proof of the GPL code copying. The botched set_vlan_ports is Juhos's GPL rtl8366_smi.c code, copied and then adapted (with a couple typos) onto Realtek's API. The comment block is byte-for-byte identical and the loop structures along with it. Someone hand-edited it and broke it in the process (which is where the pvid == 0 guard got dropped).

3 Likes
85

Last bit I’m going to post after looking more at upstream. This was entirely self-inflicted.

The openwrt RTL8366 driver is already a common core with per-chip plugins. The core is Juhos's GPL rtl8366_smi.cand it already does all the hard stuff, including the swconfig glue, the VLAN/PVID logic, the enable_vlan accessors, the bus primitives.

The driver then hands chip-specifics off through an ops table (get/set_vlan_4k, get/set_pvid, etc). Each individual chip such as the rtl8366rb & rtl8366s is just a file filling in that table plus its register map.

Supporting the Brume3 -ub chip the right way would have been one new file: rtl8366ub.c with its register map + register-level ops. Everything else (including the exact set_vlan_ports they botched) is already done properly and just inherited from the core untouched - zero upstream effort.

This would have been GPL clean (no RT SDK), bug free and publishable back to mainline with a simple PR.

The only data needed was either to get the chip’s register map/data sheet, or just probes to pull it from the hardware direct.

What they did here was likely the same or more work that doing it proper. They didn’t need to edit/re-work any of Gabor’s upstream and create bugs.

I really don’t want to be cynical, but the only reason I can see for this is if someone thought they could make a closed version by grabbing the GPL version and mixing in NDA code so they wouldn’t have to share the .ko source. Ironically, IF this is the case, it’s a pretty epic-level self-own, as GPL works the opposite. All they accomplished was to GPL the SDK code and put themselves publicly on record copying & violating GPL by not having published return source.

EDIT - I would really really like this to NOT be the reason we should infer and have GL show us with a simple push to the GL SDK.

I’m sure the team already knows that by building on OpenWRT/Linux, that the router network drivers will always have to be GPL in order to load into the kernel using GPL symbols. The only way around this is NVIDIA style - with full cleanroom code and then using Export symbols - which would then cause the kernel to declare it’s running TAINTED in order to load.

Most projects (like OpenWRT) push code first to avoid these issues and ensure obligations are met before distributing binaries.

5 Likes
86

@bruce Can you bring this to GL’s attention? It would be a shame if an amazing piece of hardware like this got stuck indefinitely without a resolution.

2 Likes
88

If they do this, this device is done for. Just imagine how many more products are on the way.

89

After multiple rounds of intensive discussions and negotiations, Realtek has officially agreed to open-source the source code for this switch.

We are currently moving forward with the preparation and pipeline work on our end. Barring any unexpected technical or administrative hiccups, we will be uploading the full source code directly to the community repository shortly.

Thank you again for your patience, your outstanding technical insights, and for pushing this issue forward. We will update this thread with the repository link as soon as it goes live!

20 Likes
90

That is good news! Great work on your side, thank you for the update!

1 Like
91

Thanks @bruce and the whole team for the efforts here! :heart:

1 Like
92

This is a great news! Thank you to @bruce and GL.inet’s team’s effort!!! You make the brilliant MT5000 great again!!!:clap:

2 Likes
93

Awwwwwwwwwwwwsome

1 Like
94

This is a fantastic great news!

2 Likes
95

@bruce This is fantastic news! GL’s opensource roots are exactly the reason that myself (and I believe many others) chose to deploy and support GL products. Seeing a re-commitment to this backed by actions is extremely encouraging!

Thank you to the entire GL team!!

PS - can you let us know where to find it once it’s posted up? I see a new gl-inet/gl-rtl8366ub repo created, but it’s empty, and no new driver source in the MT5000 sdk feed yet.

4 Likes
96

We are currently waiting for Realtek to send us the code.
Will load the code to this repo you are referring to.

It will take a little more time, so we appreciate your patience.

7 Likes
97

Hello,

A quick update!

Our R&D team has uploaded the source code for the rtl8366ub, and the same time we have submitted a PR to the OpenWrt community for review.

Source Code Repo:

PR:

If you have any questions, please communicate on this forum.
Comments in the PR are only for code review.

10 Likes
98

See those on github! Great work!!! Thanks!:clap: :grinning_face:

99

Hey @bruce . Thank you to you and the GL team for getting this published appropriately! I’ll follow up on the github PRs directly, but it’s great to see RT & GL making an effort to honor the obligations when you’re building on other’s code and the linux GPL kernel symbols.

I see you guys are getting a little bit of a hard time from the upstream (but sorry, easy to see coming), but before it gets called out there, I’d like to make the GL team aware that you’re still publishing GPL files with conflicting (and “non legal”) restriction headers. It’ll probably be a moot point considering it looks like the OWRT team is going to rewrite the driver as DSA and ditch the GL/RT code, but it would be good to have GL on record with a proper clean commit.

”This software is a confidential and proprietary property of Realtek Semiconductor Corp. Disclosure, reproduction, redistribution, in whole or in part, of this work and its derivatives without express permission is prohibited.”. It looks a little silly to have that 4 lines down from the GPL-2.0 SPDX license identifier as they are 100% mutually exclusive statements.

Just as important. I see GL is repeating a similar mistake with the Astro* code. I’ve pointed it out here but it seems to be getting ignored by the GL team. I would hope GL wants to get ahead of this before it get’s noticed by upstream copyright holders for the clear violations and those communities are less amicable about it.

I really hope the team gets that all projects built on opensource have to include published source at the very same moment that GL is releasing firmware features built on it.

6 Likes
100

Is there any updates?