So I figured out what was going on (or at least how to work around it): When I create the VLAN manually (unmanaged interface with the ID) and then use "brctl addif br-test wan2" as part of my rc.local it works fine. Unfortunately there is also something wrong with the switch though which causes weird hickups in the entire network once I connect a second device, that is because the internal switch aswell as the software bridge seem to be both doing the bridging, causing a loop. If I only use brctl in that case for setting it up (just as with the VLANs) it is perfectly fine aswell.
So to sum it up: With a little workaround you can use VLANs and the switch.
Huge thanks @robimarko for bearing with me while getting OpenWRT on this device! Great work that you did there!
After a few days I noticed another problem: If I run an iperf speedtest the entire ethernet switch somehow "locks up". It is impossible to transmit any additional data then, dmesg doesnt show anything, I was hoping to maybe see the switch driver crash or something like that but no indication what could possibly be wrong.
Could you check if its the same for you? Also maximum speed in iperf (before the crash) is 450mbit/s here.
I then tried to connect a USB Ethernet Interface to make my life easy for now but that was not even recognized at all (the Hubs are shown, the Device isn't though).
Any idea why the ipqess driver locks up? Are you experiencing the same thing when running a speedtest to a gigabit destination? How could I start to track down the issue? I'm a little surprised there is nothing in dmesg about it. Would connecting another device to another ethernet port and checking if data is still able to go through the switch be a good approach to check if its the driver? Or would that crash aswell then?
Other USB Devices get recognized, probably just some incompatibility then. Nothing in dmesg if I connect that adapter, other devices are shown properly in lsusb and dmesg.
I just tried to figure out what is going on here but seems like those ethernet lockups are somehow a little random: Sometimes they happen after 160 seconds of speedtest, sometimes they happen after 10 seconds but the device is always still reachable using Wifi.
I checked the linux master and there has been quite a lot going on in regards to the IPQ4019 (or similar) hardware since 4.19, so it's possible that the issue I am having is already fixed upstream. To make sure we don't completely "drift apart", would it be possible that we merge my (few) required changes into your repo so its easier to pull from latest master (which also includes a kernel version bump making some patches no longer necessary)? What would be a good approach to implement the partition table so the right one is selected based on the target?
There has been a lot of changes, but they are all already backported to OpenWrt or to 4.19 kernel so it made some backport patches redundant.
This are all issues with the pretty much abandoned IPQESS driver, upstream has no fixes for it as driver is not upstream.
I have no idea how to make the efi.c patch mergeable as is a hardcoded hack
I didn't even create a new board definition for it yet as I simply changed yours so it would install.
I'm slowly starting to understand how this entire "driver-mess" works. So the IPQESS Driver is for the ethernet interface in the SoC, the qca8k is for the ethernet switch (integrated into the SoC aswell?) that is connected to that ethernet interface. The vlan configuration for example has to take place in the switch so it forwards the right packets to the ethernet interface. My issue is part of the ipqess as the switch is probably still forwarding traffic, just the ethernet driver is no longer able to process the traffic it receives from the switch. Did I get that right?
Maybe it's possible to make it an include and use the preprocessor directive #if to include it if it's needed?
Unfortunately, I did not dive into the whole networking driver mess so I have no clue how it works.
But I know that under 4.19 DSA is missing a lot of important stuff to properly work, so only under 5.4 kernel, I think that IPQESS will be usable.
I will bump IPQ40xx to 5.4 as soon as there is 5.4 support in OpenWrt.
Well using preprocessors in not viable as when compiling kernel you have no idea whats the target device, it needs to be runtime based.
Aren't we compiling different images with different kernels for different devices? I thought that it would be possible to somehow check what we are compiling for at compile time, as we are also compiling in different options for different devices.
I hope that the switch to 5.4 happens soon, but it's probably going to take a few more months until that is going to happen. So you think the issue is not ipqess itself but the "surrounding" DSA stuff?
Usually OpenWrt starts with generic kernel support at rc3-4 and we get everything tested right on final release time.
IPQ40xx target wont be hard as to get working as we can drop even more upstream patches.
Targets that struggle with 4.19 wont be impacted in any way.
I am trying to port another device which is somehow similar to the Netgear Orbi Pro, the Linksys Velop WHW03.
Both are based on IPQ4019 and they use eMMC for flash.
They differ in the Wl2 chip ( Qualcomm Atheros QCA9884 vs QCA9886) and switch chip ( Qualcomm Atheros QCA8075 vs QCA8072).
I'm just learning OpenWRT and managed to get a serial connection to the device, extracted FTD and partition table -- different from Orbi's Pro.
Is it feasible to try use @robimarko tree to flash it, omitting the EFI changes made?
Or will the current kernel 4.19 or 5.4 detect the eMMC?
Do not do that.
A new tree needs to be made.
Unlike before there is full support for EMMC on IPQ4019 in OpenWrt.
Take a look on Habanero DTS for how to configure the SD/MMC and LDO nodes as well as pinctrl
Perhaps we can pump this to kernel 5.4 with better nic support?
I have rbr50 and rbs50 (i think i just have to change the hwid) and also would help to bring it into a merge request.