I've taken a Superwifi AP apart, and documented my findings on Wikidevi. This device is distributed by various ISPs under various names, but is know by Arcadyan as WE410443 .
Strangely, the device does not seem to have serial/JTAG headers? I don't see anything that resembles it? Am I overlooking something...? 
i also couldnt find it but when you take a look at the post i have linked in this topic about the BT disc you can see there is a small point for the rx
the superwifi is different from the other devices the other devices got only 128mb of ram and the superwifi 1gb
I think you're mistaken here. The Winbond W631GG6KB memory chip is 1 Gbit, which is 128 Megabyte. See the specsheet. Also, the screenshot in your first post is pretty clear 
thanks you have right 
There are quite a few test points on this device, two of them are likely to be serial. You'll often find serial near to the spi-nor chip (that makes TP4/ TP5 candidates, also because they're physically larger - easier to attach to; obviously this is merely guesswork based on the pictures). Another potential option could be the unpopulated U13 (level shifter, omitted from the production PCB - if so, careful with the voltages, they are probably below 3.3V and at SOC voltage without any protection)
After measuring, all TPx points are indeed not 3.3V, but 1.2V instead. So you can't attach a serial console without a level shifter. Or at least, I still haven't found the right points to attach to.
I've been working with @Goossens to create an image for the Arcadyan WE410443, but I'm stuck with getting our work merged.
This device is basically a clone of the Arcadyan WE420223 with an extra radio and one less ethernet port. Most critically, the flash chip (SPI-NOR), the bootloader and flash layout are the same.
The WE420223 uses the UBI filesystem layout, which is not common on SPI-NOR. I copied the UBI layout from the WE420223's device definition to the WE410443, the image worked flawlessly and I submitted a PR.
But, the UBI layout was one of the first things the reviewers commented on, we had to change it to squashfs + jffs2. Also, we had to squash the kernel and rootfs partitions.
This has led to two issues:
The bootloader expects a separate kernel partition with a nested rootfs partition. Squashing these two into a single firmware-partition (as seems common) throws the device into a bootloop.
When keeping the separate partitions, but using the squashfs + jffs2 layout, sysupgrade is broken. If I try to install the image via LuCI, everything looks fine and the device reboots, but it loads the 'old' firmware. The new image isn't actually flashed.
The first issue is easy to 'fix' by simply keeping the two separate partitions. But it seems that this directly leads to the second issue. I'm fairly sure the error is in the IMAGE/sysupgrade.bin line of the device definition, but I'm stuck troubleshooting this. I don't see any device with SPI-NOR and a squashfs + jffs2 filesystem layout using a kernel- and nested rootfs partition to use as an example.
I don't fully comprehend how or why the update recipe differs from the factory recipe, and I'm grateful for any help I can get here. For reference, the current device definition:
define Device/arcadyan_we410443
$(Device/dsa-migration)
$(Device/uimage-lzma-loader)
DEVICE_VENDOR := Arcadyan
sanderpqr marked this conversation as resolved.
DEVICE_MODEL := WE410443
IMAGE_SIZE := 32128k
KERNEL_SIZE := 4352k
KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | \
uImage none | arcadyan-trx 0x746f435d
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-kernel | \
uImage none
IMAGES += factory.trx
IMAGE/factory.trx := append-kernel | pad-to $$(KERNEL_SIZE) | append-rootfs | pad-rootfs | check-size
IMAGE/sysupgrade.bin := append-kernel | pad-to $$(KERNEL_SIZE) | append-rootfs | pad-rootfs | \
check-size | append-metadata
DEVICE_PACKAGES := kmod-mt7615-firmware -uboot-envtools
endef
TARGET_DEVICES += arcadyan_we410443
TL;DR: Using squashfs + jffs2 layout with separate kernel- and rootfs partitions breaks sysupgrade. Need help with update recipe in the device definition.
Below is the serial output of the failed sysupgrade process. It looks like sysupgrade is trying to write to a squashed firmware partition, and not to the separate kernel + rootfs partitions. I guess this means an update script is required in /target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh ?
Watchdog does not have CARDRESET support
Mon May 12 00:29:50 GMT 2025 upgrade: Sending TERM to remaining processes ...
Mon May 12 00:29:54 GMT 2025 upgrade: Sending KILL to remaining processes ...
[ 981.060648] stage2 (3670): drop_caches: 3
Mon May 12 00:30:00 GMT 2025 upgrade: Switching to ramdisk...
mount: mounting /dev/mtdblock6 on /overlay failed: Resource busy
[ 984.045291] ------------[ cut here ]------------
[ 984.054613] WARNING: CPU: 1 PID: 3670 at fs/super.c:695 generic_shutdown_super+0x128/0x16c
[ 984.071103] VFS: Busy inodes after unmount of jffs2 (jffs2)
[ 984.071114] Modules linked in: nft_fib_inet nf_flow_table_inet wireguard nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_compat nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7615e(O) mt7615_common(O) mt76_connac_lib(O) mt76(O) mac80211(O) libchacha20poly1305 iptable_mangle iptable_filter ipt_REJECT ipt_ECN ip_tables cfg80211(O) xt_time xt_tcpudp xt_tcpmss xt_statistic xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY x_tables sch_cake poly1305_mips nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c hwmon crc_ccitt compat(O) chacha_mips sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact ifb ip6_udp_tunnel udp_tunnel sha512_generic sha256_generic
[ 984.082699] sha1_generic seqiv sha3_generic jitterentropy_rng drbg md5 crypto_hw_eip93 hmac geniv rng des_generic libdes cmac authencesn authenc leds_gpio gpio_button_hotplug(O) crc32c_generic
[ 984.296493] CPU: 1 PID: 3670 Comm: busybox Tainted: G O 6.6.77 #0
[ 984.311386] Stack : 809af440 80089dec 00000126 00000004 00000000 00000000 844c9d1c 80b70000
[ 984.328044] 80a40000 808b329c 00000000 00000000 00000000 00000001 844c9cc8 8188f6c0
[ 984.344699] 00000000 00000000 808b329c 844c9c00 ffffefff 00000000 ffffffea 00000000
[ 984.361354] 844c9c0c 00000127 809b7000 ffffffff 808b329c 00000001 844c9dc8 80200540
[ 984.378010] 00000009 808bc400 809af440 7f706620 00000018 804867fc 00000004 80b70004
[ 984.394665] ...
[ 984.399532] Call Trace:
[ 984.404385] [<800079f4>] show_stack+0x28/0xf0
[ 984.413076] [<807b41f4>] dump_stack_lvl+0x60/0x80
[ 984.422441] [<8002d9b4>] __warn+0xb0/0xe4
[ 984.430440] [<8002db68>] warn_slowpath_fmt+0x180/0x188
[ 984.440669] [<80200540>] generic_shutdown_super+0x128/0x16c
[ 984.451763] [<804b8864>] kill_mtd_super+0x14/0x30
[ 984.461137] [<802a6460>] jffs2_kill_sb+0x5c/0x74
[ 984.470329] [<80200744>] deactivate_locked_super+0x4c/0xd8
[ 984.481247] [<80229bb4>] cleanup_mnt+0xb0/0x15c
[ 984.490283] [<8004fd44>] task_work_run+0x98/0xdc
[ 984.499471] [<80006f48>] do_notify_resume+0x214/0x24c
[ 984.509530] [<80002c50>] work_notifysig+0x10/0x18
[ 984.518892]
[ 984.521905] ---[ end trace 0000000000000000 ]---
Mon May 12 00:30:04 UTC 2025 upgrade: Performing system upgrade...
[ 984.679472] do_stage2 (3670): drop_caches: 3
Could not open mtd device: firmware
Can't open device for writing!
cat: write error: Broken pipe
sysupgrade aborted with return code: 256
[ 984.778727] reboot: Restarting system