I noticed that entering some vlan config, clicking "Update/Create", then
clicking "Get Configuration" resulted in Tagged/Untagged/PVID displaying
completely wrong data. It looks like the parisng in fetchVLAN() in
vlan.js was just completely disconnected from the layout of the
registers read by vlan_get() in rtl837x_port.c. Who knows how that
happened.
1. Fix fetchVLAN() member/untag parsing: the old code read bits [9:0]
as untagged and bits [10:19] as tagged, but the VLAN table register
layout is members in [9:0] and untag in [19:10]. Now correctly
derives tagged (member && !untag) and untagged (member && untag).
2. Add PVID to vlan.json response: PVID is stored per-port in separate
PVID registers (RTL837x_PVID_BASE_REG), not in the VLAN table entry.
The old code nonsensically tried to read it from bits [20:29] of the
VLAN table. Add port_pvid_get() and build a pvid bitmask in
send_vlan() so the JS can parse it correctly.
3. Remove auto-PVID logic from setC(): setC() is called by fetchVLAN()
while it's loading existing config, and so this logic mangled the
display of the existing config. Also, it doesn't make sense to
auto-set the PVID for tagged members (PVID relates to untagged
ingress.)
We use the SoC's UUID to generate a fixed MAC for a particular
switch device. The MAC generated uses a Realtek prefix and then
is followed by 3 bytes genertaed from the first 3 bytes of the
UUID xored with the last byte in order to prevent being able
to deduce the UUID from the public MAC.
RTL has up to 3 SCL pins and up to 4 SDA pins. Lets allow configuring
I2C with individual BUS numbers instead of 0/1 I2C.
This enables support for devices where SCL line is not shared between
SFP modules. MUX registry is now initialized depending on needed
pin function.
More over, some SFP pins require special MUX settings, lets initialize
those depending on SFP configuration. This adds TX Disable pin,
which right now is set to low at startup.
Caveats:
- We may still override MUX registry later
- Not sure how to handle invalid bus definitions
- Without SFP is it fine to *not* initialize anything?
- Do to RAM limitation we do inititalize output GPIO to low
logicog
Mark H. Spatz
feelfree69
logicog
chriz
TylerDurden-23
diijkstra
René van Dorst