Acer Vero W6m (6E) with OpenWrt

Got the Acer Vero W6m (6E) model for 72€

Mfg date Aug 2023

Removing it from that ugly box was not that much trouble, some rubberfeet was covering holes for screws and then it was just a matter of some bending for the top to come off.

You have to take the heatsink off if you want to remove the motherboard from the case.

The serial-connector holes are there.

Have not tried a serial-flash yet and It was quite some time since I used my usb-serial cable, but hopefully I can give a report if it works later today :slight_smile:

1 Like

Interesting. Looks very very similar... although: no Wan Ethernet port, no USB (though it might be possible to solder in a header, not entirely clear from the pic if more components are missing), and it looks like the power supply connector might be very different (though it looks the same on other pics, so...). Also unclear on the mood light - I guess it's just tiny?

The biggest loss appears to be the 2.5gbps ethernet wan port. On external pics the 'game' port has been relabeled 'internet' - but I imagine it's just 1gbps? But I'm not sure if the game port is 1 or 2.5gbps.

This looks like it could be an interesting office AP, but less useful for the home.

Specification:

16. Router Basic Specification
Processor
System MT7986 + MT7916
CPU Quad A53 2.0GHz
Memory
LPDDR 1GB
Storage 4GB
Wireless LAN
IEEE standard 802.11 a/b/g/n/ac
MU-MIMO 2+4+2 streams
2.4GHz: 2x2 MIMO streams, 1024/256
QAM,
20/40MHz, 574MBps
5GHz: 4x4 MIMO streams, 1024/256
QAM, 20/40/80/160MHz, 4804Mbps
6GHz: 2x2 MIMO streams, 1024/256
QAM, 20/40/80/160MHz, 2402Mbps
Band Tri-band, 2.4/5/6GHz
Throughput AXE7800
Ethernet
WAN 1 x 1Gbps
LAN 3 x 1Gbps
Button
Power Power-ON/OFF
WPS Yes
Form factor
Dimension 200.7 x 200.7 x 55.9 mm
Weight 810g
DC Power Jack
Input Voltage AC 100-240V, 50-60Hz, 1.6A
Power Adapter 12V/3A 36W

Yes, but its at sale for less than half the price of the Predator (selling out since im guessing it was not that popular)

The most important thing for me is an OpenWRT device capable of "mesh point" and 6GHz band.

I already have some other options such as the Asiarf AW7916-AED (M.2 card) and a Banana pi R4 with BE14

I took some time for me since my old USB-serial cable did not have any pins, so I had to fix my own doityourself solution with crap I had at home :slight_smile:

I have not flashed yet but at least now I am connected with the serial interface - will do more tomorrow.

Hi,

a few (hopefully helpful) comments:

OpenWrt installation on Acer Connect Vero W6m is exactly the same as for Acer Predator Connect W6.

Very helpful are maze's advice in https://forum.openwrt.org/t/acer-predator-w6-with-openwrt/168979/113 to hold the WPS button during power up on devices with u-boot version 2023.04 (and newer) – and kirdes' notice in https://forum.openwrt.org/t/acer-predator-w6-with-openwrt/168979/122 that a snapshot should be installed (https://github.com/openwrt/openwrt/issues/14548 is not fixed in 23.05.4).

If serial connection fails using the header holes, use the adjacent test pads.

Because predator's eth1 is missing on vero's board, the default network configuration (WAN on eth1) should be changed after OpenWrt installation if you are not using AP mode (WAN on game/"internet" port which indeed is a 1 Gbit/s port).

2 Likes

Does the existing OpenWrt firmware image detect it as 'Acer Vero W6m'? or does it claim 'Predator' - in which case it likely means it is baked into the firmware image somewhere.

Might say something in dmesg, for example on my predator:

OpenWrt 23.05.4, r24012-d8dd03c46f
 -----------------------------------------------------
root@predator:~# dmesg | egrep -i predator
[    0.000000] Machine model: Acer Predator W6
root@predator:~# cat /sys/firmware/devicetree/base/model; echo
Acer Predator W6

I guess it wouldn't be that hard to adjust the default network configuration based on some board identifier and have a shared image for Predator W6/Vero W6m, if they can be detected via the above model info...

Its claiming Predator in Luci.

The original firmware in my Vero was W6m_1.01.332433 and I saved some info:


> F0: 102B 0000
> FA: 1040 0000
> FA: 1040 0000 [0200]
> F9: 103F 0000
> F3: 1006 0033 [0200]
> F3: 4001 00E0 [0200]
> F3: 0000 0000
> V0: 0000 0000 [0001]
> 00: 0000 0000
> BP: 2400 0041 [0000]
> G0: 1190 0000
> EC: 0000 0000 [2000]
> T0: 0000 028B [010F]
> Jump to BL
> 
> NOTICE:  BL2: v2.6(release):fe7b13a4d-dirty
> NOTICE:  BL2: Built : 19:10:23, Jun  6 2023
> NOTICE:  WDT: disabled
> NOTICE:  CPU: MT7986 (2000MHz)
> NOTICE:  EMI: Using DDR4 settings
> NOTICE:  EMI: Detected DRAM size: 1024MB
> NOTICE:  EMI: complex R/W mem test passed
> NOTICE:  Verifying BL Anti-Rollback Version ... bl_ar_ver:0=0+ OK
> NOTICE:  Verifying BL Anti-Rollback Version ... bl_ar_ver:0=0+ OK
> NOTICE:  Verifying BL Anti-Rollback Version ... bl_ar_ver:0=0+ OK
> NOTICE:  Verifying BL Anti-Rollback Version ... bl_ar_ver:0=0+ OK
> NOTICE:  Verifying BL Anti-Rollback Version ... bl_ar_ver:0=0+ OK
> NOTICE:  BL2: Booting BL31
> NOTICE:  BL31: v2.6(release):fe7b13a4d-dirty
> NOTICE:  BL31: Built : 19:10:32, Jun  6 2023
> 
> 
> U-Boot 2022.07-rc3 (Jun 06 2023 - 19:08:30 +0800), Build: jenkins-YX6_factory-15
> 
> CPU:   MediaTek MT7986
> Model: mt7986-rfb
> DRAM:  1 GiB
> Core:  68 devices, 19 uclasses, devicetree: separate
> MMC:   mmc@11230000: 0
> Setting bus to 0
> Loading Environment from MMC... OK
> In:    serial@11002000
> Out:   serial@11002000
> Err:   serial@11002000
> Net:   
> Warning: ethernet@15100000 (eth0) using random MAC address - 46:5b:eb:e9:e1:98
> eth0: ethernet@15100000
> mtkautoboot gpio_reset:1
> 
> 
>   *** U-Boot Boot Menu ***
> 
>       1. Startup system (Default)
>       2. Upgrade firmware
>       3. Upgrade ATF BL2
>       4. Upgrade ATF FIP
>       5. Upgrade eMMC partition table
>       6. Upgrade single image
>       7. Load image
>       0. U-Boot console
> 
> 
>   Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit

It was built on OpenWrt 21.02-SNAPSHOT, r0-e1c639323

I had 23.05.04 up and running for a while, but the trick to overwrite mmcblk0p5 and mmcblk0p7 with 0 did not seem to have work for me.

In my efforts to fix this I might have accidentally flashed the bootloader with the sysupgrade file... (if thats even possible ?)

So I might have "bricked" it.

But Im glad that gold could verify that it works :slight_smile:

@Pulver: Best wishes that you can revive your vero without the need to fiddle around with the JTAG port (https://openwrt.org/docs/techref/hardware/port.jtag).

@maze: OpenWrt snapshot r27346 identifies an Acer Connect Vero W6m as (Machine model:) "Acer Predator W6". That could be changed with an own .dts file for the vero (or an integrated .dts file for predator and vero) and source code patches for the vero as blocktrron kindly committed for the predator (https://github.com/openwrt/openwrt/commit/7e7eb5312d7810084547bb54a4b6867c2da08182 - i.e. a patch for the file target/linux/mediatek/image/filogic.mk). Unfortunately I do not have the knowledge, a build system, and enough time to create and test the code needed – preferably with a suitable device mapper target type other than "verity", with vero's ethernet configuration ("internet" or "lan0" instead of "game", no "eth1"), with complete support for gpiod-tools, and so on.

1 Like

I found some 'used - acceptable' Vero W6m for 60$ and it should arrive tomorrow. Not much risk at that sort of price. We'll see...

I haven't had to muck around with jtag in forever: I remember soldering from scratch some hacky parallel port adapter, so it might have been ~20 years ago. However, looking at FCC photos of the insides (of the Predator) I don't see a ready made jtag connector...

I took a closer look at my Vero motherboard and no, there does not seem to be any jtag (from what I can see with my amateur eyes)
When I removed the protective paper cover on the back I got my hopes up for a second, but that was just the - non existing - usb connector.

The other spot is the missing 2.5 connector.

I have more Vero:s coming :slight_smile:

I'm worried these devices are going to be utterly unrecoverable if anything goes wrong.

Secure boot being enabled means mtk_uartboot (which is being used to recover the RT3200 from the Kiss-of-Death) is not a viable path to recovery.

This means any flashing of BL2 or FIP carries a risk of delivering a fancy paperweight. (Because the only ability to recover anything is AFAICT via serial and the bl2+fip provided uboot - so if those aren't working...)

[There's a slight chance that a FIP failure is recoverable from a functioning BL2 via some hardcoded-in-BL2 tftp logic, trying to download a FIP via some hardcoded ipaddr/serverip/filename, but who knows - certainly not worth the risk of testing this...]

Similarly (to the RT3200) don't lose the factory partition if you want working wifi - that likely stores some important wifi chip calibration information (& the macs).

Furthermore, the lack of a usb connector means there's no convenient spot to plug in something like RP2040-One, Pico-Like MCU Board Based on Raspberry Pi RP2040, 4MB Flash MCU Board, Dual-Core Arm Cortex M0+ Processor up to 133 MHz, Onboard USB Type-A Plug,Plug and Play to interact with the serial port...

I guess it all depends on what firmware version these things ship with.
(and as a reminder don't let them boot into stock firmware while connected to the internet: they'll most likely upgrade the bl2/fip and lock things down tighter)

I agree. Recovery really is nearly impossible without a usable JTAG header and with µC/SoC and eMMC in large, very difficult to (de-)solder BGA packages. I further agree that while booting from FIP partition (mmcblk0p4 / BTW: "U-Boot 2022.07-rc3"), tftp, serial, and even NFS file transmissions seem to be intended. But without MBR/GPT (34 sectors aka as predator's/vero's mmcblk0p1), and without a valid u-boot (mmcblk0p4) and u-boot environment (mmcblk0p2)?

Acer probably implemented a possibility to write to an empty or accidentally overwritten eMMC in MT7986's ROM, but without more and precise information, I also agree to this, it is more likely to brick the device than to detect this recovery method.

So for now, the only playground for OpenWrt users seem to be the two slots of boot image and root file system on partitions mmcblk0p5..8 (and ext4 "user_data" partition mmcblk0p12 of cause). The other parts of mmcblk0 should carefully not be modified until we know more.

Hi,
talking about eMMC partition layout of the Acer Connect Vero W6m, I hope the following lines can serve as a starting point for further investigations and will not be perceived as "too much".

# uname -a
Linux OpenWrt 6.6.50 #0 SMP Tue Sep 10 22:37:34 2024 aarch64 GNU/Linux
# gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.10

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Warning! Main partition table overlaps the first partition by 34 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/mmcblk0: 7733248 sectors, 3.7 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 2BD17853-102B-4500-AA1A-8A21D4D7984D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 7529471
Partitions will be aligned on 1024-sector boundaries
Total free space is 8158 sectors (4.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   2            8192            9215   512.0 KiB   8300  u-boot-env
   3            9216           13311   2.0 MiB     8300  factory
   4           13312           17407   2.0 MiB     8300  fip
   5           17408           82943   32.0 MiB    8300  kernel
   6           82944         1131519   512.0 MiB   8300  rootfs
   7         1131520         1197055   32.0 MiB    8300  kernel1
   8         1197056         2245631   512.0 MiB   8300  rootfs1
   9         2245632         2266111   10.0 MiB    8300  qcidata
  10         2266112         2286591   10.0 MiB    8300  qcidata1
  11         2286592         3335167   512.0 MiB   8300  rootfs_data
  12         3335168         7529471   2.0 GiB     8300  user_data
# blkid
/dev/mmcblk0p1: PTTYPE="PMBR"
/dev/mmcblk0p2: PARTLABEL="u-boot-env" PARTUUID="19a4763a-6b19-4a4b-a0c4-8cc34f4c2ab9"
/dev/mmcblk0p3: PARTLABEL="factory" PARTUUID="8142c1b2-1697-41d9-b1bf-a88d76c7213f"
/dev/mmcblk0p4: PARTLABEL="fip" PARTUUID="18de6587-4f17-4e08-a6c9-d9d3d424f4c5"
/dev/mmcblk0p5: PARTLABEL="kernel" PARTUUID="971f7556-ef1a-44cd-8b28-0cf8100b9c7e"
/dev/mmcblk0p6: BLOCK_SIZE="262144" TYPE="squashfs" PARTLABEL="rootfs" PARTUUID="309a3e76-270b-41b2-b5d5-ed8154e7542b"
/dev/mmcblk0p7: PARTLABEL="kernel1" PARTUUID="a975393e-a9bc-491f-8133-aeecf6075307"
/dev/mmcblk0p8: BLOCK_SIZE="262144" TYPE="squashfs" PARTLABEL="rootfs1" PARTUUID="32798804-a1a7-4f95-ad5a-48939498675b"
/dev/mmcblk0p9: UUID="e6c59f15-aede-412a-82ae-813af6649f5d" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="qcidata" PARTUUID="3c607e69-0038-4195-a819-77157883e2df"
/dev/mmcblk0p10: UUID="8896f8ba-b705-404f-96d5-c1d5ce866d7d" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="qcidata1" PARTUUID="613e2af8-cfe5-4701-8e67-facda9ffdd71"
/dev/mmcblk0p11: LABEL="rootfs_data" UUID="7d7071ce-1b08-42ff-ac89-04b1407e337b" BLOCK_SIZE="4096" TYPE="f2fs" PARTLABEL="rootfs_data" PARTUUID="5881ba72-d78f-4cbb-8fef-871aeb4b8eef"
/dev/mmcblk0p12: UUID="bf546920-2916-4655-9a09-5ef4a92ffac2" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="user_data" PARTUUID="e6f92786-dc2f-4b91-b33c-92b3f18c2548"
/dev/loop0: LABEL="rootfs_data" UUID="1939b7f2-1dd2-11b2-b705-705a6f5a0586" BLOCK_SIZE="4096" TYPE="f2fs"
# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0          7:0    0 506.3M  0 loop /overlay
mmcblk0      179:0    0   3.7G  0 disk 
├─mmcblk0p1  179:1    0    17K  0 part 
├─mmcblk0p2  179:2    0   512K  0 part 
├─mmcblk0p3  179:3    0     2M  0 part 
├─mmcblk0p4  179:4    0     2M  0 part 
├─mmcblk0p5  179:5    0    32M  0 part 
├─mmcblk0p6  179:6    0   512M  0 part /rom
├─mmcblk0p7  179:7    0    32M  0 part 
├─mmcblk0p8  259:0    0   512M  0 part 
├─mmcblk0p9  259:1    0    10M  0 part 
├─mmcblk0p10 259:2    0    10M  0 part 
├─mmcblk0p11 259:3    0   512M  0 part 
└─mmcblk0p12 259:4    0     2G  0 part 
mmcblk0boot0 179:8    0     2M  1 disk 
mmcblk0boot1 179:16   0     2M  1 disk 
# dd if=/dev/mmcblk0p2 bs=4 count=1 2>/dev/null | xxd
00000000: c5bd dc48
# dd if=/dev/mmcblk0p2 bs=4 skip=1 2>/dev/null | strings | sed -E ':x;s/^(.*sn=.{6})(.*)[^X]/\1\2X/;tx'
2gMAC=70:5A:6F:5A:05:83
2gpwd=ConnectVkND
2gssid=VeroW6m-SNqT-2.4GHz
5gMAC=70:5A:6F:5A:05:82
5gpwd=ConnectVkND
5gssid=VeroW6m-SNqT-5GHz
6gMAC=70:5A:6F:5A:05:84
6gpwd=ConnectVkND
6gssid=VeroW6m-SNqT-6GHz
LANMAC=70:5A:6F:5A:05:86
WANMAC=70:5A:6F:5A:05:85
baudrate=115200
bootcmd=mmc read 0x40000000 0x00004400 0x0010000; fdt addr $(fdtcontroladdr); fdt rm /signature; bootm 0x40000000
bootdelay=5
bootmenu_0=Startup system (Default)=mtkboardboot
bootmenu_1=Upgrade firmware=mtkupgrade fw
bootmenu_2=Upgrade ATF BL2=mtkupgrade bl2
bootmenu_3=Upgrade ATF FIP=mtkupgrade fip
bootmenu_4=Upgrade eMMC partition table=mtkupgrade gpt
bootmenu_5=Upgrade single image=mtkupgrade simg
bootmenu_6=Load image=mtkload
cu=1
dn=Acer Connect Vero W6m
dual_boot.current_slot=1
dual_boot.slot_1_invalid=0
efuse=1
ethaddr=f6:5c:0a:05:7e:98
fdtcontroladdr=7f7fced0
hw_id=1111
mbsn=C2AYX6XXXXXXXXXXX
pj_id=00
pw=vfzdReF6dMASZIZlfy1J9kVWj2A=
qsn=YX6MSTXXXXXXXX
sku=GBL
sn=FFG2FTXXXXXXXXXXXXXXXX
stderr=serial@11002000
stdin=serial@11002000
stdout=serial@11002000
# strings /dev/mmcblk0p4 | grep -Ei 'u-boot|tftp|nfs|kermit|192'
** Invalid partition type "%.32s" (expect "U-Boot")
u-boot,mmc-env-partition
U-Boot.armv8
ipaddr=192.168.1.1
serverip=192.168.1.2
## Ready for binary (kermit) download to 0x%08lX at %d bps...
## Binary (kermit) download aborted
u-boot,i2c-offset-len
u-boot,i2c-transaction-bytes
u-boot,bootconf
[0;33m*** Starting Kermit transmitting ***
[93;41m*** TFTP client failure: %d ***
Input U-Boot's IP address:
192.168.1.1
Input TFTP server's IP address:
192.168.1.2
*** U-Boot Boot Menu ***
u-boot,mmc-env-offset
Cannot autoload with NFS
Cannot autoload with TFTPGET
*** ERROR: NFS version not supported
/nfsroot/%02X%02X%02X%02X.img
File transfer via NFS from server %pI4; our IP address is %pI4
u-boot,dm-pre-reloc
u-boot,dm-pre-proper
u-boot,dm-spl
u-boot,dm-tpl
u-boot,efi-partition-entries-offset
u-boot,off-on-delay-us
TFTP client
Kermit
u-boot
U-Boot
u-boot,bootdev-system
u-boot,boot-std
load binary file over serial line (kermit mode)
boot image via network using NFS protocol
tftpboot
boot image via network using TFTP protocol
boot image via network using BOOTP/TFTP protocol
u-boot,bootdev-mmc
u-boot-env
u-boot,bootdev-eth
TFTP error: 
TFTP error: '%s' (%d)
tftpblocksize
tftpwindowsize
tftptimeout
TFTP timeout (%ld ms) too low, set min = 1000 ms
tftptimeoutcountmax
TFTP timeout count max (%d ms) negative, set to 0
TFTP %s server %pI4; our IP address is %pI4
U-Boot 2022.07-rc3 (Jun 06 2023 - 19:08:30 +0800)
=u-boot-env
u-boot,mmc-env-partition
u-boot,dm-pre-reloc
1 Like

Serial console installed!


I had to fully disassemble it in order to solder in the 3 pin serial header. That involved disconnecting, unwiring and unscrewing and removing all four internal antennas and more importantly the eight wires. It's not hard per say, but it's a pretty annoyingly time consuming process.

So far I've only verified the serial connection works, and that it looks like I (still) have the old hackable version of bl2/fip - so I should easily be able to install OpenWrt (need to back everything up first though)

1 Like

Impressive! :smiley:

I was just about to post this picture from my second Vero :slightly_smiling_face:

1 Like

I bought the Acer Predator W6d used (and sadly updated) and had some trouble installing openwrt, but I got it working and outlined my steps in a pull request for the W6d. I too was wondering how to get around the secure boot and it "should" be possible to disable the active signature by burning an efuse and set a new one. But I didn`t mess with it, I like the device and don't need a paperweigth :wink:

Btw. is the normal W6 firmware working for this device? The phy should be different and maybe the switch? That can probably be seen in the bootlog or the device-tree.

Do you mean OpenWRT for W6 ? Yes. Acer ? No idea.

I have not done any serious attemps to recover my presumed "dead" Vero, but it still gives some start information through the serial console:

F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 1006 0033 [0200]
F3: 4001 00E0 [0200]
F3: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 2400 0041 [0000]
G0: 1190 0000
EC: 0000 0000 [2000]
T0: 0000 028B [010F]
Jump to BL

NOTICE:  BL2: v2.6(release):fe7b13a4d-dirty
NOTICE:  BL2: Built : 19:10:23, Jun  6 2023
NOTICE:  WDT: disabled
NOTICE:  CPU: MT7986 (2000MHz)
NOTICE:  EMI: Using DDR4 settings
NOTICE:  EMI: Detected DRAM size: 1024MB
NOTICE:  EMI: complex R/W mem test passed
ERROR:   BL2: Failed to load image id 3 (-2)

Looking at golds information regarding the boot process it looks like its trying to read a tftp server at 192.168.1.2 before starting uboot ? So in theory it would be possible to recover by serving it the correct image in a tftp server at 192.168.1.2 ?

But looking at the lights at the switch its connected to and seeing that it does not seem to have any network activity going on in this short start sequence - i think its "bricked"

Anyway, I have another one now :slight_smile:

sadly updated ... I got it working and outlined my steps ...

Thank you very much. So holding down the RESET button in addition to the WPS button was necessary. Had you tried it without before?

it "should" be possible to disable the active signature by burning an efuse and set a new one

Really? – Having read https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-update.html#tbbr-firmware-update-tbbr-fwu meanwhile and assuming TBBR FWU is used by Acer to recover eMMC content, correctly implemented, a gap in the "trust chain" seems to be unlikely.

So in theory it would be possible to recover by serving it the correct image in a tftp server at 192.168.1.2 ?

I do not think so. The string's order in /dev/mmcblk0p4 does not necessarily reflect the order of the boot sequence, and IPv4 addresses 192.168.1.1 and 192.168.1.2 may only be default input values.

At least you see console messages, and u-boot is not totally unavailable.

Compared to your previous post, it seems that the handover from BL2 to BL31 fails before you can get a u-boot console and prepare for a tftp boot.

Maybe someone more familiar with u-boot can help.

1 Like