IPQ40xx / IPQ806x SOC page

Talk about Documentation
1

Inspired by:

That's valuable information that should be easier to find for interested users.
IMHO this would fit into
https://openwrt.org/docs/techref/hardware/soc/soc.qualcomm.ipq40xx
however, this page does not yet exist.

Does someone knowledgeable feel like creating that page?

For examples what to document on this page see other already existing pages listed in https://openwrt.org/docs/techref/hardware/soc

P.S.: Same for https://openwrt.org/docs/techref/hardware/soc/soc.qualcomm.ipq806x

2 Likes
2

Answering to this:
By applying these changes: https://github.com/NoTengoBattery/openwrt/commit/3433c6308d59bc84e80a03e7a89a4a89ce646aa0

Two of these problems are “solved”:

  • VLANs are not reserved by the driver, therefore UCI is responsible of setting up VLAN1 and VLAN2 in “userspace”.
  • GMAC1 (eth1, which is not a “real device”) disappears and the interfaces become eth0.1 and eth0.2 for LAN and WAN.

More testing is needed about the problem with ARP, but if this improves the situation it can be more useful to push these changes rather than a “hacking guide”, but that’s only a suggestion.

3

According to IPQ40x8/x9 Software User Guide, section 7.1

The EDMA driver configures the EDMA queuing interface. It also creates two virtual network devices:
eth0 (WAN) and eth1 (LAN). All packets received on the eth0 interface are forwarded to the ESS WAN
group and all packets received on eth1 interfaces are forwarded to the ESS LAN group.

So there is only one CPU port, and eth1 interface is virtual and created by its driver like DSA

4

Be careful, as the IPQ40x9 has more interfaces than does the IPQ40x8, which may be better supported in future driver implementations.

5

I would fix this myself but I have no hardware to test. As for the EA6350v3, it just works. Out of the box and as expected (according to my lower number of testers).

Still my never-asked opinion is to apply the fix temporarily to make it “work as expected” (even if only a few devices benefit) rather than writing a guide about how it does not work as expected. Both are temporary solutions, anyway.

As for the IPQ4019, there must be a way to apply these patches to IPQ4018 without affecting the IPQ4019... or maybe using a plain old if in C may do the trick.