WNDAP360 with current 22.03 trunk

I have Netgear WNDAP360 access point with 19.07.10 and it works perfect. I understand that the 19.07 branch is already frozen and will no longer be developed. Therefore, I am testing trunk builds for this model. However, in the default version, everything is not so good there. At the moment I have 2 problems, one of which was solved. Tested trunk 20967.

  1. Natively, the device has a serial console with a default speed of 9600 baud. After loading and starting (tftpboot and bootm), the console starts working at a speed of 115200 from a certain moment (i think when bootconsole disabled) and you have to reconnect with a new speed, which is not very convenient.
    I found out that in 19.07 kernel options used MIPS_CMDLINE_FROM_BOOTLOADER, while current trunks use MIPS_CMDLINE_FROM_DTB.
    As a result, on 19.07, the kernel parameters look like this:
    board=WNDAP360 console=ttyS0,9600 mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7744k(firmware),64k(nvram)ro,64k(art)ro rootfstype= squashfs noinitrd
    For vanilla trunk 20967 like this:
    console=ttyS0,115200 rootfstype=squashfs,jffs2

After a little dirty hack in the form of setting a kernel parameter at 20967 MIPS_CMDLINE_BUILTIN_EXTEND i got this:
rootfstype=squashfs,jffs2 console=ttyS0,9600 rootfstype=squashfs root=31:03 init=/sbin/init mtdparts=ar7100-nor0:256k(u-boot),64k(u-boot-env),1024k(vmlinux.gz.uImage),6208k(rootfs),512k(var),64k(manufacturing-data),64k(ART)

And my 9600 speed working good from U-boot till root@OpenWrt:/#. Therefore, I have a question - is it possible to do the same more correctly through the config of the OpenWRT itself, and not the kernel. To make it easier to transfer between updates and new buildroots? I have suspicions that this is done through DTS, the question is how to include this in the OpenWRT config?

  1. After successfully winning at the speed of the console, a more serious problem arises. In principle, the console speed can be switched - it's okay and used rarely. There is a more serious problem - the ethernet port does not work. I successfully boot from tftpboot and bootm with kernel from 20967, everything looks fine. But at the same time, I cannot ping, ssh or access the web interface (I built with LuCI). For debugging, I added tcpdump-mini package - when pinging, it shows that arp requests are coming and arp responses are leaving, and that's it, nothing more:
ARP, Request who-has 192.168.1.1 tell 192.168.1.50, length 46
ARP, Reply 192.168.1.1 is-at 00:03:7f:e0:00:96, length 28

From the computer side, I receive messages about the unavailability of the host:

From 192.168.1.50 icmp_seq=1 Destination Host Unreachable
From 192.168.1.50 icmp_seq=2 Destination Host Unreachable

Perhaps the fact that the access point is connected through the POE-injector affects? The question then is - why does this not affect the tftpboot stage and on 19.07 branch? There may be a problem with the firewall or something like that - tell me how to temporarily disable it completely for debug. Perhaps the created br-lan bridge also affects? All settings are default. The same result occurs with images from the page https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=ath79%2Fgeneric&id=netgear_wndap360

inherits bootargs = "console=ttyS0,115200"; from

you should be able to override the SOC wide *.dtsi include in ar7161_netgear_wndap360.dts, untested:

--- a/target/linux/ath79/dts/ar7161_netgear_wndap360.dts
+++ b/target/linux/ath79/dts/ar7161_netgear_wndap360.dts
@@ -9,6 +9,10 @@
 	compatible = "netgear,wndap360", "qca,ar7161";
 	model = "Netgear WNDAP360";
 
+	chosen {
+		bootargs = "console=ttyS0,9600";
+	};
+
 	aliases {
 		led-boot = &led_power_orange;
 		led-failsafe = &led_power_orange;

2 Likes

Tested, and it works! It would be cool to see this patch in the upcoming sources. I'm not a great git specialist, but I think the next git pull will give me a conflict with a manually patched file)

It remains to solve another problem with the Ethernet port, this is more important.

There is dmesg (with patched console speed and 20967 trunk), if it helps:

[    0.000000] Linux version 5.15.72 (openwrt@build) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r20877-7d6032f310) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 Tue Oct 18 07:50:05 2022
[    0.000000] printk: bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] MIPS: machine is Netgear WNDAP360
[    0.000000] SoC: Atheros AR7161 rev 2
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32480
[    0.000000] Kernel command line: console=ttyS0,9600 rootfstype=squashfs,jffs2
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    0.000000] Writing ErrCtl register=00000000
[    0.000000] Readback ErrCtl register=00000000
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 109252K/131072K available (5373K kernel code, 581K rwdata, 1020K rodata, 13304K init, 206K bss, 21820K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 51
[    0.000000] CPU clock: 680.000 MHz
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 5621354254 ns
[    0.000002] sched_clock: 32 bits at 340MHz, resolution 2ns, wraps every 6316128254ns
[    0.092873] Calibrating delay loop... 452.19 BogoMIPS (lpj=2260992)
[    0.227854] pid_max: default: 32768 minimum: 301
[    0.283381] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.370901] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.465732] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build
[    0.559765] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.677481] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.758849] pinctrl core: initialized pinctrl subsystem
[    0.822771] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    1.206398] PCI host bridge to bus 0000:00
[    1.255416] pci_bus 0000:00: root bus resource [mem 0x10000000-0x16ffffff]
[    1.337709] pci_bus 0000:00: root bus resource [io  0x0000]
[    1.404433] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    1.499685] pci 0000:00:11.0: [168c:ff1d] type 00 class 0x020000
[    1.571625] pci 0000:00:11.0: reg 0x10: [mem 0x00000000-0x0000ffff]
[    1.646965] pci 0000:00:12.0: [168c:ff1d] type 00 class 0x020000
[    1.718933] pci 0000:00:12.0: reg 0x10: [mem 0x00000000-0x0000ffff]
[    1.794484] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[    1.873724] pci 0000:00:11.0: BAR 0: assigned [mem 0x10000000-0x1000ffff]
[    1.954992] pci 0000:00:12.0: BAR 0: assigned [mem 0x10010000-0x1001ffff]
[    2.036723] clocksource: Switched to clocksource MIPS
[    2.098082] NET: Registered PF_INET protocol family
[    2.156689] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    2.243858] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    2.343945] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    2.436656] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    2.528357] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    2.612777] TCP: Hash tables configured (established 1024 bind 1024)
[    2.688987] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    2.767179] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    2.850794] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    2.918578] PCI: CLS 0 bytes, default 32
[    3.153090] workingset: timestamp_bits=14 max_order=15 bucket_order=1
[    3.234860] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    3.304718] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    3.423726] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[    3.500525] printk: console [ttyS0] disabled
[    3.551720] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 10, base_baud = 10625000) is a 16550A
[    3.656976] printk: console [ttyS0] enabled
[    3.757060] printk: bootconsole [early0] disabled
[    3.880564] spi-nor spi0.0: mx25l6405d (8192 Kbytes)
[    3.940126] 5 fixed-partitions partitions found on MTD device spi0.0
[    4.016321] OF: Bad cell count for /spi@1f000000/flash@0/partitions
[    4.091418] OF: Bad cell count for /spi@1f000000/flash@0/partitions
[    4.166812] OF: Bad cell count for /spi@1f000000/flash@0/partitions
[    4.241971] OF: Bad cell count for /spi@1f000000/flash@0/partitions
[    4.317571] Creating 5 MTD partitions on "spi0.0":
[    4.375037] 0x000000000000-0x000000040000 : "u-boot"
[    4.439627] 0x000000040000-0x000000050000 : "u-boot-env"
[    4.504294] 0x000000050000-0x0000007e0000 : "firmware"
[    4.568666] 2 uimage-fw partitions found on MTD device firmware
[    4.639698] Creating 2 MTD partitions on "firmware":
[    4.699142] 0x000000000000-0x000000300000 : "kernel"
[    4.760325] 0x000000300000-0x000000790000 : "rootfs"
[    4.820712] mtd: device 4 (rootfs) set to be root filesystem
[    4.889550] 1 squashfs-split partitions found on MTD device rootfs
[    4.963730] 0x0000006e0000-0x000000790000 : "rootfs_data"
[    5.030119] 0x0000007e0000-0x0000007f0000 : "nvram"
[    5.089584] 0x0000007f0000-0x000000800000 : "art"
[    5.566303] ag71xx 19000000.eth: connected to PHY at mdio.0:01 [uid=004dd04e, driver=Generic PHY]
[    5.673285] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii
[    5.747747] i2c_dev: i2c /dev entries driver
[    5.800524] NET: Registered PF_INET6 protocol family
[    5.868507] Segment Routing with IPv6
[    5.912542] In-situ OAM (IOAM) with IPv6
[    5.959621] NET: Registered PF_PACKET protocol family
[    6.020212] 8021q: 802.1Q VLAN Support v1.8
[    6.111284] Freeing unused kernel image (initmem) memory: 13304K
[    6.183314] This architecture does not have kernel memory protection.
[    6.260504] Run /init as init process
[    6.304358]   with arguments:
[    6.304363]     /init
[    6.304368]   with environment:
[    6.304372]     HOME=/
[    6.304377]     TERM=linux
[    6.886244] init: Console is alive
[    6.927549] init: - watchdog -
[    6.990829] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[    7.087298] usbcore: registered new interface driver usbfs
[    7.153185] usbcore: registered new interface driver hub
[    7.216946] usbcore: registered new device driver usb
[    7.290178] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    7.380354] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[    7.477424] init: - preinit -
[    7.834123] random: jshn: uninitialized urandom read (4 bytes read)
[    8.056025] random: jshn: uninitialized urandom read (4 bytes read)
[    8.161597] random: jshn: uninitialized urandom read (4 bytes read)
[   10.642053] procd: - early -
[   10.677016] procd: - watchdog -
[   11.304964] procd: - watchdog -
[   11.344190] procd: - ubus -
[   11.386856] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.465533] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.542268] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.623007] procd: - init -
[   12.382196] kmodloader: loading kernel modules from /etc/modules.d/*
[   12.960033] urngd: v1.0.2 started.
[   13.057489] Loading modules backported from Linux version v5.15.58-0-g7d8048d4e064
[   13.148335] Backport generated by backports.git v5.15.58-1-0-g42a95ce7
[   13.412616] random: crng init done
[   13.453381] random: 29 urandom warning(s) missed due to ratelimiting
[   13.646095] PPP generic driver version 2.4.2
[   13.700808] NET: Registered PF_PPPOX protocol family
[   13.800649] kmodloader: done loading kernel modules from /etc/modules.d/*
[   46.347255] br-lan: port 1(eth0) entered blocking state
[   46.409919] br-lan: port 1(eth0) entered disabled state
[   46.472779] device eth0 entered promiscuous mode
[   49.457277] eth0: link up (1000Mbps/Full duplex)
[   49.576818] br-lan: port 1(eth0) entered blocking state
[   49.639489] br-lan: port 1(eth0) entered forwarding state
[   49.838476] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready

any news about gigabit ethernet? Iam facing now same issue, on gigabit poe (switch, injector) no network, on 100mbit works.

Wow, i changed on my PC speed to:
ethtool -s eth0 autoneg off speed 100 duplex full
and it start to works. But, gigabit eth is required option for 5GHz networks.

I also noticed, although I set full duplex on the computer, half duplex was set on the port of the access point itself. And no matter what speed - 10 or 100 megabits. It seems that with the new firmware, the access point does not know how to do full duplex? At the same time, when there is auto-detection of speed on the computer and point, it successfully sets 1000 full duplex:
[ 44.017303] eth0: link up (1000Mbps/Full duplex)
and this, when i put 100/10 full duplex on PC:

[  245.777198] eth0: link up (100Mbps/Half duplex)
[ 1070.577175] eth0: link up (10Mbps/Half duplex)

Perhaps we can solve this problem if we compare the DTS from another access point, which also has 1 port and is also on ar7161/ag71xx:

[    0.000000] SoC: Atheros AR7161 rev 2
[    4.010352] ag71xx 19000000.eth: connected to PHY at mdio.0:01 [uid=004dd04e, driver=Generic PHY]
[    4.019833] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii

ok, btw, I noticed this one old topic, and there is mentioned about this issue and how to fix (something with pll for phy ?), I am not so familiar with the details, maybe as startpoint or doublecheck..

https://forum.archive.openwrt.org/viewtopic.php?id=43042&p=1
Post#18 + Post#19

1 Like

Yes! Thanks for the tip! I fix it =)
I added
pll-data = <0x11110000 0x00001099 0x00991099>;
in eth0 section of file target/linux/ath79/dts/ar7161_netgear_wndap360.dts. Also i added fixed serial console speed 9600 in this file.
But now, i see no wireless interfaces, i keep digging =) Please check wifi availability on default openwrt builds (stable 22 and snapshot) - i tried both, but didnt see any ath9k wlans with ifconfig -a

I think DTS is fully incomplete, why 22.03 recommended for WNDAP360 with such failures?

huh, nice.
On my wndap360 with default install (frist time after stock fw), all ifaces are visible.
wlan0 and wlan1 are up and working, I can do wifi via 2.4g and 5g channels.
used this img:
https://downloads.openwrt.org/releases/22.03.2/targets/ath79/generic/openwrt-22.03.2-ath79-generic-netgear_wndap360-squashfs-sysupgrade.bin

only issue with eth0 (br-lan later) on gigabit-link at the moment.
Did wifi work, before your changes on pll->dts?

Hmm, strange.
I tried 19.07.10 my custom build (defconfing + some packages) - everything works.
Tried official 22.03.2 - serial and eth bug, but wifi works
Tried customize 22.03.2 via defconfig and selecting some packages - no wifi, weird console speed and no gig eth.
Tried customize 22.03.2 via openwrt default config with selecting ethtool+tcpdump+wpad_wolfssl - serial and eth bug, but wifi works.

Thats weird, defconfig produces fault .config which leads to not working wifi, or when im selecting WNDAP360 as single target i got not all needed packages?

Comparison of two modded configs: openwrt config.buildinfo and defconfig. In both of them, i select only single target device WNDAP360, LUCI, wpad-wolfssl (i need EAP), ethtool and tcpdump-mini:

diff orig my
4,13d3
< CONFIG_ALL_KMODS=y
< CONFIG_ALL_NONSHARED=y
< CONFIG_DEVEL=y
< CONFIG_AUTOREMOVE=y
< CONFIG_BPF_TOOLCHAIN_BUILD_LLVM=y
< # CONFIG_BPF_TOOLCHAIN_NONE is not set
< CONFIG_BUILDBOT=y
< CONFIG_COLLECT_KERNEL_DEBUG=y
< CONFIG_HAS_BPF_TOOLCHAIN=y
< CONFIG_IB=y
15,17d4
< CONFIG_KERNEL_BUILD_DOMAIN="buildhost"
< CONFIG_KERNEL_BUILD_USER="builder"
< # CONFIG_KERNEL_KALLSYMS is not set
20d6
< CONFIG_MAKE_TOOLCHAIN=y
23,24c9,18
< CONFIG_PACKAGE_libbpf=m
< CONFIG_PACKAGE_libelf=m
---
> # CONFIG_PACKAGE_kmod-leds-reset is not set
> CONFIG_PACKAGE_kmod-nls-base=y
> # CONFIG_PACKAGE_kmod-owl-loader is not set
> CONFIG_PACKAGE_kmod-usb-chipidea=y
> CONFIG_PACKAGE_kmod-usb-chipidea2=y
> CONFIG_PACKAGE_kmod-usb-core=y
> CONFIG_PACKAGE_kmod-usb-ehci=y
> CONFIG_PACKAGE_kmod-usb-gadget=y
> CONFIG_PACKAGE_kmod-usb-phy-nop=y
> CONFIG_PACKAGE_kmod-usb-roles=y
50,51d43
< CONFIG_PACKAGE_px5g-wolfssl=y
< CONFIG_PACKAGE_qosify=m
57,58d48
< CONFIG_PACKAGE_tc-full=m
< CONFIG_PACKAGE_tc-mod-iptables=m
64,68d53
< CONFIG_PACKAGE_zlib=m
< CONFIG_REPRODUCIBLE_DEBUG_INFO=y
< CONFIG_SDK=y
< CONFIG_SDK_LLVM_BPF=y
< CONFIG_USE_LLVM_BUILD=y
72d56
< CONFIG_VERSION_CODE_FILENAMES=y

We need to understand which of the options is necessary to include a device for a working Wi-Fi in the profile, since from my point of view, there are a lot of things that are not quite necessary in the config.buildinfo =)

BTW, i compiled new image with config.buildinfo where i select only WNDAP360 (no additional packages) + fixed DTS with serial 9600 and eth working:
first boot kernel image
sysupgrade to flash
patched dts

I checked this image and everything works: gigabit ethernet, console 9600 and wifi. So here the problem with a non-working wifi is not in DTS, but in the set of packages specified in the device profile WNDAP360.

Yep, i found that fcking bird - owl. In device profile of WNDAP360 there is DEFAULT_kmod-owl-loader=n, but it required to start wifi devices. I manually added CONFIG_PACKAGE_kmod-owl-loader=y and now everything works - gigabit eth, 9600 console and wifi! I dont know why, but in result config bin/targets/ath79/generic/config.buildinfo this option is not included. I would like to see all these changes in the next minor release, or at least in snapshots: DTS console/eth fixes, and CONFIG_PACKAGE_kmod-owl-loader=y in device profile.

Result images: first tftpboot image, image to flash
It seemed to me, but in my opinion these images works a little faster than the one that comes with the default config from config.buildinfo.

2 Likes

I would add one more tweak to get the power LED to go green for normal running in the DTS:
In target/linux/ath79/dts/ar7161_netgear_wndap360.dts
Replace the led-running variable with &led_power_green in the aliases section, and add this to the leds section:

led_power_green: power_green {
                        label = "green:power";
                        gpios = <&gpio 2 GPIO_ACTIVE_LOW>;
                };
1 Like

Reviving this for not only 22.03, but 23.05 too with the following question - The publically available build targets essentially soft brick the AP. Should WNDAP360 really be listed as supported in this condition?

There are three issues that occur with builds 22.03 through 23.05 that while two appear to have been addressed in this thread, haven't made it into trunk, so therefore remain unresolved. I summarise them here:

  1. Console baud rate switches from 9600 to 115200 as the serial port is initialised mid boot. If a user follows the installation instructions for booting the kernel image from memory, they lose readability, and could assume a crash. Inconvienient, but can be worked around by reconnecting at 115200 to see the boot messages to completion. Fixed with this modification.

  2. LAN interface appears to come up, but does not transfer data and without errors. This subsequently blocks scp transfer of the sysupgrade.bin during stock FW replacement, and later breaks br-lan if a sysupgrade is performed from within openwrt.

It can be worked around as above. Thje proper fix is to set the correct PLL rate.

GitHub issue

  1. Power LED is only available as orange. fixed with this modification.

The custom build by @droncheg on 22.03.2 is working as one would expect, but any attempt to upgrade to 23.05 or even snapshot results in a soft brick, so the build files are still missing these patches. I'm not sure that it is intended that users need to make thier own custom builds after failing with the officially supported builds. Point 2 is especially gnarly.

What is the protocol here for getting the current "supported" build suspended to prevent users falling foul of the problems, and is there someone who can take responsibility for patching?

Relevant Pull request

thx @Squelch for summarize the things.
any news, about autoneg on gigabit link issue is fixed or not?
Iam still staying on @droncheg version (builded 1 year ago, thx for that!)

because:

The current stable version series of OpenWrt is 23.05, with v23.05.2 being the latest release of the series. It was released on 15. November 2023.

1 Like

Hi folks! Since main devs forgot about our device, i maked new DTS for 23.05.2 and builded firmware.
Kernel (for first install), sysupgrade (for upgrade from old OpenWRT), modified DTS and .config (for build ourself) - available here

Ethernet port works (max speed 1Gb), Power LED are green when booted, console port speed at 9600.

Warning: dont know why, but it required to reboot after first flash sysupgrade and first boot, else you got non-working eth port (only 1 reboot required, afterwards everything works).

2 Likes

Thank you. and yes, getting this working as it should on the current build will make life a little easier.

And our saviour arrives :point_up:
Thanks for the new build @droncheg
Seriously though, your 22.03 build got me up and running - and kept the family happy, but I'd like to get the official build up to date too.
From what I can gather, anyone with an interest and the ability can be a developer in this community run project. There are just a few guidlines to follow. I had set time aside this weekend to clone and identify when and why the regressions that broke things happened, and then take the necessary steps for getting patches submitted.

The steps should be as follows:

  • We need to formally raise three issues on GitHub - One for each of the bugs.
  • Test the fixes to make sure they are sound.
  • Submit a patch for each bug referencing the bug report.
  • Accept feedback and change suggestions if required.
  • Patches get accepted into main branch
  • Profit

I had set time aside to do these at the weekend after I'd set up my build environment, but as @droncheg now has a 23.05 build, we can use that for the testing in the meantime.

I'll raise the actual bug reports if that's ok? I strongly believe these are regressions from the original support effort caused by the newer generic ath79 base. I'll also try and identify when that happened which helps to keep things neat, and also helps provide rationale for patch acceptance. I can also submit pull requests for each bug in isolation with credit to yourself @droncheg if you feel you cannot?

I'll install the 23.05 build this evening, and start testing.

It would seem that something got lost when the ar71xx target was removed in favour of ath79. In its prior format, the settings relating to all three issues were in this file.

/target/linux/ar71xx/files/arch/mips/ath79/mach-wndap360.c

It looks like there was a large restructuring of the repositiory with many directory branches being removed wholesale. Here is the commit that removes the old WNDAP360 configuration along with everything ar71xx:

The new path should be something like:

/target/linux/ath79/dts/ar7161_netgear_wndap360.dts

Note the change of filetype to .dts.
However, there was no ar7161_netgear_wndap360.dts in existence since the mass deletion around 19.07.10 until spring last year when it was created as part of what I presume to be part of a larger change related to using nvmem instead of the troublesome OWL kernel module that @droncheg had trouble with.

The necessary entries for the serial port Baud, PLL frequency, and LEDs were not reproduced from the original mach-wndap360.c file. This is understandable as any reference to these specific settings lay in the archived forum, and 3 year old deletions.

As suspected, it is a regression, and all three bugs (LEDs have been improved) came about from the same cause.

Tnx for commits, hope it will be included in main tree. I had troubles with GIT, sorry. I'm just technician, not programmer =)
Feel free to submit bugreports/pull requests/etc under your name - our joint mission is a working WNDAP360 under current trunk (or atleast releases), not popularity or hype =)

1 Like