Acer Vero W6m (6E) with OpenWrt

So if you directly connect this to another Linux machine and run tcpdump on it, and then boot it (possibly while holding reset), you should (possibly maybe if you're lucky) see arp requests. Those arp requests will tell you what its IP is, and what the IP of the TFTP server it is trying to reach is expected to be. Configure the TFTP server IP (ie. what it is arping for) on your interface.

Basically:
ip -4 addr add 192.168.1.254/24 dev eth0
assuming eth0 is your Linux box nic and 192.168.1.254 is what it is arping for (I think the default is ipaddr=192.168.1.1 serverip=192.168.1.254).

Now reboot it again (likely while holding reset), now the arp request should get an answer from your box. If this works, you should see (in tcpdump) a TFTP request for something like YX6-fip.bin (or YX6-sw-bl2.img or something like that). Let me know if you get that far and we can try to figure out where to go from there.

No guarantees though! Your paperweight is less of a paperweight than mine (where 'Failed' happens instead of 'Jump to BL') - I was trying to downgrade back to the non-Ctrl+C required firmware, but utterly failed... even though I did the downgrade from u-boot - but apparently it doesn't check sigs or something.

2 Likes

I can confirm that sysupgrade can be applied smoothly to Acer Connect Vero W6m ("W6m") and to Acer Predator Connect W6 ("W6e") from/to current snapshots (i.e. sysupgrade to 2024-09-20's r27466-f368e2d5ec):

scp <user>@<sshd_server>:/<openwrt_download_directory>/openwrt-mediatek-filogic-acer_predator-w6-squashfs-sysupgrade.bin /tmp
sysupgrade -v /tmp/openwrt-mediatek-filogic-acer_predator-w6-squashfs-sysupgrade.bin

If you created backups of partitions mmc0blk5..8 before overwriting them, have fun with different versions of OpenWrt 21.02-SNAPSHOT:

dumpimage -T flat_dt -p 1 -o mmcblk0p5_ftd-1.dtb mmcblk0p5.bin ; dtc -I dtb -O dts -o - mmcblk0p5_ftd-1.dtb >mmcblk0p5.dts 2>warnings-p5.log
sudo unsquashfs -d rootfs mmcblk0p6.bin

dumpimage -T flat_dt -p 1 -o mmcblk0p7_ftd-1.dtb mmcblk0p7.bin ; dtc -I dtb -O dts -o - mmcblk0p7_ftd-1.dtb >mmcblk0p7.dts 2>warnings-p7.log
sudo unsquashfs -d rootfs1 mmcblk0p8.bin

Interresting - and fun :smiley:

I tried "sudo tcpdump -i eth0 -v" on a ubuntu computer with only one ethernet port and started the Vero, both with and without holding the reset button.

Unfortunately it did not detect anything on any of the Vero:s ethernet ports.

I had the serial connected so I could see the output from Vero and there is a pause period for 6-7 seconds between:

NOTICE:  EMI: complex R/W mem test passed
ERROR:   BL2: Failed to load image id 3 (-2)

So something IS happening, but I cant see what it is.

I tried tcpdump without "-i eth0" but I got so much ubuntu info so it was useless - is there a better tcpdump command than the one I tried ?

Are you certain eth0 is the right network interface? I guess if it's not outright failing it probably is... (What does 'ip link' show on that machine...)

Usually I run 'tcpdump -ee -vv -s 1600 -i eth0 arp' - but I kind of doubt it'll help here - especially if you say the switch port ain't blinking...

You could also try holding the reset button for a long time (20-30 seconds) once it's already powered on... I definitely saw my device trying to automatically tftp something ("YX6-sb-bl2.img" based on some notes) in response to something I did -- but it's possible this was fip(bl31+bl33=uboot) reacting to reset button. I was seeing this on an otherwise healthy (ie. booting) device - likely with the newer Acer bl2/fip - I think it was probably before I soldered in a serial connection.

In your case it looks like BL2 is ok, but the FIP payload is corrupt/gone.
It's looking likely this won't work...

Probably would need to directly flash the mmc somehow... (jtag? desoldering? ugh...)

1 Like

Yes, I tried a luci system upgrade to the latest snapshot on my second Vero yesterday and it worked - however it did not save my settings as I asked so I had a little scare before I realized it was just reset to defaults.

6GHz is working on the snapshot :slight_smile:

I've been comparing OpenWrt boot logs from Predator and Vero, and looking at the (mother)boards.

It looks like someone with crazy soldering skills (and some extra tiny components) could likely get USB and the 2.5gbps Ethernet port up and running on the Vero. USB stack seems to initialize fine - don't see any difference between the two devices. Ethernet (eth1) fails to initialize due to lacking PHY - but I think that's likely exactly what you'd expect with the visibly missing parts.

However, the components are insanely small, so anyone ever actually performing this sort of surgery seems super duper unlikely, and thus I think we should just disable usb/eth1 on Vero (and rename 'game' to 'internet' and make it WAN) - probably/presumably somewhere in the devicetree (along with the name).


I also think trying to hold on to factory images/partitions is undesirable, as you're at risk of things 'updating' and locking you down further. First thing you want to do when you get one of these devices is brick the factory kernel/rootfs so it can't spontaneously/erroneously boot and update and lock you out.

This suggests it might be desirable to repartition the MMC...
I think everything mmcblk0p5+ is in practice reworkable without risk of affecting the (secure) boot process in a non recoverable way (ie. worst case recover via uboot -> tftp -> initramfs). That's the kernel/rootfs/kernel1/rootfs1/qcidata/qcidata1/rootfs_data/user_data partitions.
I'd probably leave kernel as is, but increase rootfs size and possibly kill the rest.

This has nearly 4GB space, and OpenWrt is constrained to ~512MB atm.

As things stand I don't think dualboot/recovery/etc will work anyway...
at least not unless we muck with the uboot env 'bootcmd' in mmcblk0p2 and change the kernel offset.

I'll have to take a look at the content of these partitions and see if there's anything useful... (p8..p12 are mountable, and p8 likely has overlay appended to it)

Alternatively maybe we should have kernel (32M) + rootfs (512M) + /data (3.5GB), with /data not being cleared on upgrade?

Also, considering how big the rootfs is / could be... it seems the image is needlessly small - I'm constantly finding and installing small things which really should just be built into the rootfs.

Oh, curious... I have 6GHz working on 23.05.4 (phone speedtest.net'ed @ approximately just under 900mbps on it)... the only thing I had to do was set country code to 'CA' [California] instead of 'US' to bypass the (AFAICT incorrect) passive-scan restriction (by my reading of FCC docs, indoor APs can do 18dBm on the entire 6GHz band, and clients are restricted to 6dBm less then the AP). The 'CA' regulatory db seems to match the 'US' one except it doesn't have the passive-scan. Maybe that's what was changed @ HEAD...

When using OpenWrt snapshots, I use the command line most of the time.
With sysupgrade -v the settings were saved, rewritten, and applied correctly:

# sysupgrade -l
/etc/config/dhcp
/etc/config/dropbear
/etc/config/firewall
/etc/config/luci
/etc/config/luci-opkg
/etc/config/network
/etc/config/openssl
/etc/config/radius
/etc/config/rpcd
/etc/config/system
/etc/config/ubootenv
/etc/config/uhttpd
/etc/config/uhttpd-opkg
/etc/config/wireless
/etc/dropbear/dropbear_ed25519_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/group
/etc/hosts
/etc/inittab
/etc/luci-uploads/.placeholder
/etc/nftables.d/10-custom-filter-chains.nft
/etc/nftables.d/README
/etc/opkg/keys/b5043e70f9a75cde
/etc/passwd
/etc/profile
/etc/radius/clients
/etc/radius/users
/etc/rc.local
/etc/shadow
/etc/shells
/etc/shinit
/etc/sysctl.conf
/etc/sysupgrade.conf
/etc/uhttpd.crt
/etc/uhttpd.key

At least the log said so, and I can confirm that for system, network, and wireless configuration, and I see the other old config files on the new system. (Current snapshot's /etc/config/luci and /etc/config/uhttpd differ from the recovered versions and will be saved with -opkg extensions when re-installing luci after the sysupgrade.)

6GHz is working on the snapshot :slight_smile:

Yes, and mesh works (...for me) too. There are still some quirks (iw doesn't list mesh stations correctly, dhcpoffers will not be forwarded to new wifi clients in AP/bridge mode with dnsmasq disabled, ...), but not especially with regard to the W6m/W6e sysupgrade images. (They are snapshot versions.)

I know that Ubuntu has other names for network ports now but im sure that eth0 is right on this one - ip link says

"$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether d8:3a:dd:9f:77:d4 brd ff:ff:ff:ff:ff:ff

"
I also attached a network cable with internet after the test with Vero when tcpdump was still running and saw it explode with information :wink:

But Im still doing some more tests with this, and another computer - Its not important to recover my "bricked" Vero but its interesting to see if its possible to find some information :slight_smile:

Yeah, 'eth0' is definitely right for you. I guess it's just not working :sob:

Probably needs (de)soldering to get at emmc directly and/or jtag it.
Technically some magic via the serial port might still be viable... but likely requires tooling and secure boot keys we don't have (or don't know we have...)

See also some interesting stuff about mediatek secure boot at https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html

1 Like

So I bought https://www.amazon.com/gp/product/B073R6XJND/ref=ppx_yo_dt_b_search_asin_title and while they work, after some time (many minutes) the USB bus/interface on my linux desktop errors out and the serial connection tty interface vanishes. Seems to happen with all 3 of them (or at least 2 of them, but I think I've tried all 3) - so not random bad luck with the hw...

It's not even enough to unplug the usb adapter and plug it back in - if the Vero is still powered on. I guess it pulls power somehow via the gnd/tx/rx pins and stays hosed. Feels like the usb chip is 'crashing'...

I have to unplug both sides of the usb adapter (or unplug one, and power off the Vero) in order for it to start working again. Super annoying.

It (eventually) breaks even with an otherwise idle serial connection.

I have an entirely identical looking -
JBtek WINDOWS 8 Supported Debug Cable for Raspberry Pi USB Programming USB to TTL Serial Cable - that I bought back in 2018 - that doesn't have this problem (but it's now hard wired into my Predator).

The good one is 'usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0' while the bad ones are 'usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0'

Good:

usb 1-5: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-5: Product: USB-Serial Controller
usb 1-5: Manufacturer: Prolific Technology Inc.

Bad:

[40822.495799] usb 1-9: new full-speed USB device number 6 using xhci_hcd
[40822.622539] usb 1-9: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[40822.622567] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[40822.622584] usb 1-9: Product: USB-Serial Controller D
[40822.622597] usb 1-9: Manufacturer: Prolific Technology Inc. 
[40822.625026] pl2303 1-9:1.0: pl2303 converter detected
[40822.626107] usb 1-9: pl2303 converter now attached to ttyUSB0
[40831.062805] pl2303 ttyUSB0: pl2303_get_line_request - failed: -32
[40831.063303] pl2303 ttyUSB0: pl2303_get_line_request - failed: -32
[40875.003547] pl2303 ttyUSB0: error sending break = -32
[40933.370390] pl2303 ttyUSB0: pl2303_get_line_request - failed: -32
[43166.128745] usb usb1-port9: disabled by hub (EMI?), re-enabling...
[43166.128774] usb 1-9: USB disconnect, device number 6
[43166.338451] pl2303 ttyUSB0: pl2303_set_control_lines - failed: -19
[43166.338477] pl2303 ttyUSB0: error sending break = -19
[43166.338915] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[43166.338988] pl2303 1-9:1.0: device disconnected
[43166.561965] usb 1-9: new full-speed USB device number 7 using xhci_hcd
[43166.676986] usb 1-9: device descriptor read/64, error -71
[43166.900998] usb 1-9: device descriptor read/64, error -71
[43167.123964] usb 1-9: new low-speed USB device number 8 using xhci_hcd
[43167.283078] usb usb1-port9: attempt power cycle
[43167.669974] usb 1-9: new low-speed USB device number 9 using xhci_hcd
[43172.722117] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[43178.354225] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[43178.562204] usb 1-9: device not accepting address 9, error -62
[43178.676193] usb 1-9: new full-speed USB device number 10 using xhci_hcd
[43178.676462] usb 1-9: Device not responding to setup address.
[43178.882474] usb 1-9: Device not responding to setup address.
[43179.090206] usb 1-9: device not accepting address 10, error -71
[43179.090316] usb 1-9: WARN: invalid context state for evaluate context command.
[43179.090395] usb usb1-port9: unable to enumerate USB device

(though the precise error message vary)

Any ideas? Is this firmware upgradable? I don't recall ever hitting issues like this with usb serial dongles...

Sorry, I dont have any solutions to your serial-adapter problems - your cable has the same design my old cable has. I had some problems with my first flash, but those were related to the connection of the board.

Still, I went to my local store and bought a new setup of serial-connectors for my second flash - i got a "variety-pack" - including one with usb-c, so I would be prepared if one broke down for some reason.

The usb-c one came with holes and separate pins for connections.

I did not pay much for these at the local store, but still - looking at aliexpress I found the exact same ones and could roughly by 10 pieces for what I paid for 1 at the local store.

They were actually so cheap that you could buy and install a usb-c connector for each device you try to flash.

Did some more tests, but no - the ethernet ports on the Vero seems to be inactive.

I ended up grabbing one each of:

https://www.amazon.com/dp/B09YYYTTT3 [turns out this is 5V not 3.3V]

Slightly expensive experiment, but I guess I'll see which of these work, and return any bad ones (incl. https://www.amazon.com/dp/B073R6XJND which at 9$ for 3 was simply too good of a deal to be true...).

In other news I think I've figured out a better bootcmd (it actually honours partition table layout) - though it needs a bit more testing. Keeping fingers crossed that I don't end up with a brick when I start mucking with partitions tomorrow.

1 Like

I just realized something :slight_smile:

Interested people might have already noticed that all the antenna cables on the Vero are detachable.

I did, however, not notice these holes on the box before:

So there is actually 6 holes to use for external antennas if you want :slight_smile:

I was not planning on using the original box at all, but i am starting to change my mind... maybe a paint-job :smiley:

Or, of course - you can just use the hole for your serial cable.

Where you conveniently can use the Veros cable-holder to keep it safe and in place :slight_smile:

I was aware of all of this (indeed I took it all the way apart to solder mine)...
The real question is where to find a matching set of 6 antennas with 8 (ifirc) appropriate length wires...
I guess from a bricked predator is the easiest answer?
But if you have that you're probably simply better off putting the vero motherboard in the predator enclosure.

I think one thing we've failed to notice/mention in this thread so far:

The Vero apparently lacks all 6 antenna * 3 color (RGB) = 18 leds.
I'm guessing they've simply not been soldered to the board. I think I can see where they're missing on my saved photos - I don't feel like reopening the unit to recheck.

The only leds are the 8 activity/linkspeed indicators on the 4 ethernet ports, and the blue/cyan (or likely RGB) 'kool' led/light (which so far has no linux driver).

Both the reset and wps buttons work in OpenWrt, and I've succeeded in reading the reset button from U-Boot (via 'gpio read reset mt7986_pinctrl9; print reset; with 1=normal 0=pressed). But I can't seem to find the WPS button state. [edit: nvm wps is ...pinctrl10 - it's just not labelled]

In the above photo I actually attached a antenna connector to hold the antenna in place, it was a little bit tricky since i assume its not made for removable antennas -but you can make it work.

Im also the guy that has problems letting go of old electronics so personally it would not be a problem finding antennas and cables with the right connector :wink:

On a more technical standpoint - is there a way to read and save the original firmware from acer with a new Predator/ Vero with a serial connector ?

Im assuming its not since I have not seen such a file.

I would guess you are searching for the saves command to transfer memory areas filled from emmc using the mmc command. If you have a tftp server already connected to the LAN port, it may be easier/faster to use the tftput command.

If you only need the kernel and rootfs partitions that will be replaced by your OpenWrt installation, an obvious way to read and save factory installed bl2/fip/kernel-image/rootfs partitions from emmc is to dd/scp them while installing OpenWrt after first reboot before sysupgrade. That's what post 22 was referring to (but not mentioning every partition mmcblk0p* or mmcblk0boot*).

1 Like