This is because the networking part of the SoC is not reset with warm and soft reboots, and I'm not sure what the best way is to deal with this. This device should have a GPIO wired to the SoC's hard reset (you'll have to figure out which one). If you add a gpio-restart node to the DTS, you'll have a reliable way again to reboot the device.
OK, thanks. Could you please give me some hint how to figure out the correct GPIO? I am quite new to this...
I see that you have posted a link with gpio-restart for DGS-1210-10. I will try this out. Fingers crossed that its the same GPIO for the DGS-1210-26...
Success! Adding
gpio-restart {
compatible = "gpio-restart";
gpios = <&gpio1 34 GPIO_ACTIVE_LOW>;
open-source;
};
to DTS did the trick.
Thanks for your help!
1 Like
Can you submit a device support patch to OpenWrt if everything (that can work) works for you? Then others can also use it on their devices 
Yes, this was my plan
I will probably do so next weekend. I have not tested much yet. For example I would like to check if the SFP slots are working before submitting a patch.
By the way, I see the following kernel messages during bootup:
[ 19.066125] rtl83xx_fib_event_work_do: FIB4 failed
[ 19.071517] rtl83xx_fib_event_work_do: FIB4 failed
[ 19.090773] rtl83xx_fib_event_work_do: FIB4 failed
[ 19.105725] rtl83xx_fib_event_work_do: FIB4 failed
[ 23.409846] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[ 23.419245] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[ 23.425031] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[ 23.445848] rtl83xx_fib4_del: no such gateway: 0.0.0.0
Are they safe to ignore? I did not notice any impact so far.
They are safe to ignore. This is related to the Packet Inspection Engine, which tells you that it will not offload certain routing stuff, in particular no default routes. I left this in as info messages to make sure people are aware that HW offload of routing might happen (on RTL83xx static IPv4 routes to a network/host via a neighbor), which may require you to set up offloaded firewall rules. The routing offload evidently happens before the kernel can make firewall-decisions. You can think of it as a short-circuit between two switch ports where IP headers are being transformed in-between. Standard home setups even directly behind a DSL modem are safe, though.
2 Likes
It looks like the GPIO-s are the same on the whole DGS-1210 series as my 1210-28 uses the same ones
Hi Sander,
sorry, I did not see at first that you had the set_affinit() function. Normally it in enclosed in #ifdef CONFIG_SMP and I used my mobile to reply. Anyway, I replaced the present implementation with the file I took from your repository, but I basically get the same result: rcu-stalls when trying to run it with SMP enabled:
There seems to be a locking bug in realtek_rtl_of_init() causing that oops, and then there is an issue with the affinity function, see line 89, maybe you need to return IRQ_SET_MASK_OK_DONE instead, I do not completely understand the difference. At this point I am really very sick of VSMP on the 930x. Sebastian and I worked on this hours every day all of October and we are at this point not sure there are no hardware issues with that SoC in addition to the broken R4K timer IRQ. After all there is absolutely no device running VSMP on that platform out there, only incomplete hints of code. I will proceed creating the PR without VSMP for the 930x as planned and focus on the RTL839x and RTL931X with (V)SMP and the new features.
Thanks for testing the driver!
I noticed this is common, but it's not required. struct cpu_chip always has an irq_set_affinity member, so there's no need to guard it with an #ifdef.
That warning from line 300 is because the devicetree format has changed. Check arch/mips/boot/dts/realtek/rtl83xx.dtsi in that branch to see how the parent interrupts need to be defined, and how to use the two-cell interrupt specifiers. This format may not be final though; depends on the feedback I'll get upstream. The second cell for an interrupt specifier would be the (zero-based) index in the list of parent interrupts of the interrupt controller.
AFAICT IRQ_SET_MASK_OK_DONE and IRQ_SET_MASK_OK are handled in the same way, but I also don't understand what the difference is. It's related to an IRQ being "managed", but I have no idea what that means. At first sight, IRQ_SET_MASK_OK appears to be the correct one:
* IRQ_SET_MASK_OK - OK, core updates irq_common_data.affinity
* IRQ_SET_MASK_NOCPY - OK, chip did update irq_common_data.affinity
* IRQ_SET_MASK_OK_DONE - Same as IRQ_SET_MASK_OK for core. Special code to
* support stacked irqchips, which indicates skipping
* all descendant irqchips.
I believe the #ifdefs are supposed to preserve space in the binary if no SMP is being configured. If you define that function static when SMP is not set, the compiler will complain. But any module function should be defined static unless called from somewhere else. If you do not define it static, the compiler will not complain but I am not sure the linker leaves it out of the binary.
I am not sure I like the 2 IRQs properties in one cell. This sounds as if the device can freely set the mapping to the SoC IRQ. But what about a shared IRQ between devices?
The drive might actually work (I did not do any stress testing). I am using this .dtsi:
with this .dts:
and I am getting this:
Note the missing network devices. I had this is the past, I don't think it has to do with something wrong in the .dts, because the same .dts worked in non-SMP. Maybe you have an idea?
I can try this also next week on an rtl839x device. This is promising!
Which it can, that's what the interrupt routing registers (IRR0-IRR3) are for. But you are right that there can be only one route per SoC interrupt, and the 2-cell specifiers allow for conflicting routing selections for shared interrupts. That's mostly a theoretical issue though, because I haven't seen multiple peripherals being connected to a single SoC interrupt yet.
You could compare this to interrupt specifiers on a GPIO pin. One device could require a rising edge, while another might need a falling edge. If both devices request their specific type of interrupt, that would result either in an error or a non-functioning device. If both devices specify the same interrupt type (any edge), they could share an interrupt.
The same applies for sharing SoC interrupts (in theory). If a SoC interrupt is requested (mapped to a VIRQ) multiple times, then the driver will detect that. The current routing value is checked, and if it doesn't match the requested one, the mapping will fail. This will show up in the device's logs, so developers writing new devicetrees will see this issue. If two devices were to specify the same route, there is no problem and the driver will accept that (but then it would actually only be mapped once).
Edit: As an extra side note, I think the 2-cell specifiers make more sense with regards to separation of concerns. The interrupt controller doesn't know a priori which peripherals connect where, so it can't make any decision about the priority that interrupt should get. When specifying interrupts for e.g. the timers, information on which timer gets higher priority would be located in the timer node.
OK, I'll buy that, but I am wondering whether these arguments can be used in lieu of being able to time-travel as required upstream 
There is another point, for which you maybe have an idea. The SoC-IRQ mask register is per VPE, so the SoC IRQs need to be enabled when a second CPU is being booted up, especially for the Timer-IRQ because that CPU would otherwise immediately stall. If you take one of the not so ordinary SoC IRQs (say 4) and look where this is done, you can see that this is always done for each architecture in some architecture-specific SMP code, but never by a driver, especially the irq-driver:
$ rg STATUSF_IP4 arch/mips/
arch/mips/kernel/smp-mt.c
113: STATUSF_IP4 | STATUSF_IP5 |
arch/mips/kernel/smp-cmp.c
35: change_c0_status(ST0_IM, STATUSF_IP2 | STATUSF_IP3 | STATUSF_IP4 |
arch/mips/kernel/smp-cps.c
380: STATUSF_IP4 | STATUSF_IP5 |
arch/mips/ralink/irq.c
124: else if (pending & STATUSF_IP4)
arch/mips/sibyte/sb1250/smp.c
40: unsigned int imask = STATUSF_IP4 | STATUSF_IP3 | STATUSF_IP2 |
arch/mips/sibyte/sb1250/irq.c
225: unsigned int imask = STATUSF_IP4 | STATUSF_IP3 | STATUSF_IP2 |
arch/mips/sibyte/bcm1480/smp.c
51: unsigned int imask = STATUSF_IP4 | STATUSF_IP3 | STATUSF_IP2 |
arch/mips/sibyte/bcm1480/irq.c
241: unsigned int imask = STATUSF_IP4 | STATUSF_IP3 | STATUSF_IP2 |
arch/mips/include/asm/mipsregs.h
355:#define STATUSF_IP4 (_ULCAST_(1) << 12)
$ rg STATUSF_IP4 drivers/irqchip/
$ rg STATUSF_IP4 drivers/
At the moment I simply patch smp-mt.c, because if they can do that for a GIC (yay, the RTL931X is covered) and Malta, then we can do that for the RTL9300. But: how will this work with generic MIPS?
The missing drivers are probably some work queue that does not get called to initialize device drivers, probably interplay between IRQs and timer...
My latest attempt at dealing with the lack of time-travel keeps the old spec, but deprecates it. The corrected specifications require a two-parts compatible (e.g. "realtek,rtl8380-intc", "realtek,rtl-intc") instead of only the most generic part. I would then like to deal with this in driver by just ignoring interrupt-map altogether, since Marc noted the driver can do whatever it feels like (to some extent) with the DT info.
I am very aware of this fact 
At the moment, I am still trying to understand a few things. The SoC interrupt driver is loaded very early during boot, when only VPE0 is online. Adding a chained handler to the parent interrupt correctly enables it on that VPE. As you note this configuration is then not copied to VPE1 on MIPS_GENERIC when VPE1 is brought online at a later point in the boot process. I hope I can let the interrupt subsystem handle enabling the parent interrupt on all CPUs (VPEs), but I still need to figure out how exactly I can do this.
The MIPS CPU interrupts are percpu interrupts, and I finally feel like I'm starting to realize the implications that carries. I think that, in principle, the SoC IRQs are also percpu, since they can fire and be handled independently for each VPE. But I still need to play around with this concept a bit, to see how SoC IRQs should be allocated then. Most peripherals see the SoC IRQ as a single interrupt line (like a single GPIO pin), but the GPIO peripheral on RTL93xx can in fact route its interrupts to both VPEs independently. To cleanly implement this, this may require percpu SoC interrupts, rather than a CPU affinity setting at the level of the SoC interrupt controller.
This is definitely the case for the timer (or maybe one can see it the other way around there: the timer creates per-cpu IRQs in order to allow more than one CPU to run), but it is also probably the key to better network performance of these devices, from the RTL8390 onward: the interrupt-routines for network RX/TX are relatively heavy and if you think about e.g. NAT, there is not much the other CPU could do in parallel. So one needs to balance the IRQs across the CPUs.
Sebastian's and my idea was to figure out strategies to improve performance on the RTL931X, where the IRQ infrastructure (balancing and affinity) and timers as well as SMP works out of the box. So once we are sure the drivers are safe to use under SMP and with balanced IRQs we can look at affinity settings and balancing for devices, with an evident focus on the Ethernet driver.
Sounds like a generic question unrelated to what's being discussed here. Better open a separate topic.
You could Block incoming packets on port 67 on all but the port where the real dhcp server sits. This should block rogue servers. It can be done with tc flower so works at the switch level entirely in hw with wire speed. This sounds very interesting. Please report back.
dhcp snooping is actually a function of L2 level switches, but I did a keyword search in the community, it seems that openwrt does not support dhcp snooping.
And those two device models are TP-Link switch models.
Yes, the official firmware of these two models of switches does not support dhcp snooping, this restriction may be quite common.
If some unmanaged switches can install openwrt, it might be very interesting. Usually these 24 or 48 port switches have better hardware performance, and the official firmware usually has many limitations.
The black hole mac address is also very interesting.
This is a Realtek thread. You don't even know what's in your devices:
This is not a TP-Link thread.
1 Like
A post was split to a new topic: OpenWrt installation on GS1900-10HP
Hi.
I have the XGS1010-12 switch (looks identical to XGS1210 but officially has no management support). Zyxel has no firmware to download for it. I opened it and it looks just like the 1210: (https://biot.com/switches/zyxel_xgs1210-12), with same 9302B chip and same RAM.
What is the easiest way to connect to the serial port? Do I need some special hardware? I have a USB->9pin serial adapter, and also an arduino if that is useful.
Can I dump out the current firmware via tftp from the bootloader? Can I test custom firmware by loading it directly to RAM and starting it from there (without touching the stock flash)?
1 Like