VoCore2: Compile OpenWrt 21.02 in MacOS

Finally OpenWrt new version comes to stable. There are many great new feature for new Linux kernel and also improve stable for OpenWrt, why not have a try?

First, everything is same as usual, make an image by Disk Utility, 10GB is enough.

Clone from OpenWrt, I use github version, it is faster than openwrt server: git clone https://github.com/openwrt/openwrt.git -b openwrt-21.02

We can not use make, because it will throw error: /Volumns/OpenWrt21/include/toplevel.mk:29: *** Please use a newer version of GNU make. The version shipped by Apple is not supported.  Stop.

Use brew install make, then call gmake menuconfig will fix such problem.

After menuconfig select correct settings, we can directly call gmake V=s to start the make process.

After a while, it will stop at “Checking for c++filt…“, it is for libstdc++-v3, we need to go to build_dir libstdc++-v3 folder, modify configure file, delete from line 79170 to 79296 to avoid checking such command. No idea why it stuck there…and c++filt seems not critical if not exists.

Then just keep building, rest seems smoothly.

Next blog I will check if there is any bug need to patch for this new version.

VoCore2: Compile Latest Wifi Driver 2

Because of the macro is pretty complex, have to use a trick. The old version Makefile works fine, so we can use its macro define.

Grab the Makefile command line first:

mipsel-openwrt-linux-musl-gcc -Wp,-MD,/Volumes/OpenWrt18/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-p4rev-120395/build/../src/embedded/os/linux/.rt_pci_rbus.o.d  -nostdinc -isystem /Volumes/OpenWrt18/staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/../lib/gcc/mipsel-openwrt-linux-musl/7.3.0/include -I./arch/mips/include -I./arch/mips/include/generated  -I./include -I./arch/mips/include/uapi -I./arch/mips/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80000000 -DLINKER_LOAD_ADDRESS=0x80000000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -mno-branch-likely -msoft-float -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float -ffreestanding -fno-stack-check -march=mips32r2 -mtune=34kc -Wa,--trap -DTOOLCHAIN_SUPPORTS_VIRT -I./arch/mips/include/asm/mach-ralink -I./arch/mips/include/asm/mach-ralink/mt7620 -I./arch/mips/include/asm/mach-generic -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Os -fno-caller-saves --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 -fstack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -femit-struct-debug-baseonly -fno-var-tracking -Wdeclaration-after-statement -Wno-pointer-sign -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -I/Volumes/OpenWrt18/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-p4rev-120395/build/../src/include -I/Volumes/OpenWrt18/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-p4rev-120395/build/../src/embedded/include -I/Volumes/OpenWrt18/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-p4rev-120395/build/../src/ate/include -DCONFIG_SUPPORT_OPENWRT=y -DCONFIG_RALINK_MT7628=y -DNEW_RATE_ADAPT_SUPPORT -DUAPSD_SUPPORT -DUAPSD_DEBUG -DMT_PS -DWSC_INCLUDED -DWSC_SINGLE_TRIGGER -DWSC_AP_SUPPORT -DWSC_V2_SUPPORT -DDOT11W_PMF_SUPPORT -DSOFT_ENCRYPT -DMBSS_SUPPORT -DMT7628 -DMT_BBP -DMT_RF -DRTMP_RBUS_SUPPORT -DRTMP_RF_RW_SUPPORT -DMT_MAC -DRTMP_MAC_PCI -DRTMP_PCI_SUPPORT -DRTMP_FLASH_SUPPORT -DDMA_SCH_SUPPORT -DRTMP_EFUSE_SUPPORT -DCONFIG_ANDES_SUPPORT -DRESOURCE_PRE_ALLOC -DNEW_MBSSID_MODE -DENHANCE_NEW_MBSSID_MODE -DENHANCED_STAT_DISPLAY -DFIFO_EXT_SUPPORT -DMCS_LUT_SUPPORT -DUSE_BMC -DTHERMAL_PROTECT_SUPPORT -DCAL_FREE_IC_SUPPORT -DAGGREGATION_SUPPORT -DPIGGYBACK_SUPPORT -DWMM_SUPPORT -DLINUX -Wall -Wstrict-prototypes -Wno-trigraphs -DCONFIG_AP_SUPPORT -DSCAN_SUPPORT -DAP_SCAN_SUPPORT -DDOT11_N_SUPPORT -DDOT11N_DRAFT3 -DSTATS_COUNT_SUPPORT -DIAPP_SUPPORT -DDOT1X_SUPPORT -DCONFIG_RA_NAT_NONE -DDBG -DIP_ASSEMBLY  -DMODULE -mno-long-calls  -DKBUILD_BASENAME='"rt_pci_rbus"'  -DKBUILD_MODNAME='"mt7628"' -c -o /Volumes/OpenWrt18/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-p4rev-120395/build/../src/embedded/os/linux/rt_pci_rbus.o /Volumes/OpenWrt18/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-p4rev-120395/build/../src/embedded/os/linux/rt_pci_rbus.c


Compare Makefile, we can get the defines. Update Makefile…

    CONFIG_RALINK_MT7628=y \
    CONFIG_MT7628_UAPSD=y \
    CONFIG_MT7628_MAC=y \

Then call “make package/mt7628/compile V=s”

Because there is no patch, we will get a lot of errors…I find most of the problem is not critical…Like this:

/Volumes/OpenWrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt7628-wifi/mt7628_wifi_ap/../mt7628_wifi/embedded/common/wsc.c:9903:2: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if

The driver internal Makefile default has -Werror, so such warning from new compiler gcc are dealed as error. That can be removed. Rest problem is because of new Linux kernel modify, so final patch like this:

--- a/mt7628_wifi_ap/Makefile
+++ b/mt7628_wifi_ap/Makefile
@@ -533,7 +533,7 @@
-               -Wall -Wstrict-prototypes -Wno-trigraphs -Werror -Wframe-larger-than=4096
+               -Wall -Wstrict-prototypes -Wno-trigraphs -Wframe-larger-than=4096
--- a/mt7628_wifi/embedded/common/cmm_info.c
+++ b/mt7628_wifi/embedded/common/cmm_info.c
@@ -97,7 +97,6 @@
-		MTWF_LOG(DBG_CAT_ALL, DBG_SUBCAT_ALL, DBG_LVL_OFF, ("Driver version-%s %s %s\n", AP_DRIVER_VERSION, __DATE__, __TIME__));
 #endif /* CONFIG_AP_SUPPORT */
--- a/mt7628_wifi/embedded/os/linux/rt_profile.c
+++ b/mt7628_wifi/embedded/os/linux/rt_profile.c
@@ -236,7 +236,7 @@
 			// TODO: need to roll back when convert into OSABL code
-				 fsize = (ULONG)srcf->f_dentry->d_inode->i_size;
+				 fsize = (ULONG)srcf->f_path.dentry->d_inode->i_size;
 				if (buf_size < (fsize + 1))
 					buf_size = fsize + 1;
 #endif /* OS_ABL_SUPPORT */
--- a/mt7628_wifi/embedded/common/wsc.c
+++ b/mt7628_wifi/embedded/common/wsc.c
@@ -9847,7 +9847,7 @@
 	UCHAR		apIdx;
-#ifdef LINUX
+#ifdef LINUX_SIG
 /* +++  added by YYHuang@Ralink, 08/03/12 */
--- a/mt7628_wifi/embedded/os/linux/rt_proc.c
+++ b/mt7628_wifi/embedded/os/linux/rt_proc.c
@@ -29,7 +29,7 @@
 #include <linux/kernel.h>
 #include <linux/types.h>
 #include <linux/proc_fs.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
 #include "rt_config.h"

Then we can successfully get the mt7628.ko file.

VoCore2: Compile Latest Wifi Driver(version 20190925)

MediaTek wifi driver already supported WPA3, and works stable; compared to the opensourced one, still has high chance(20~30%) disconnect while using, and speed is very unstable. So before I can understand and fix the opensource wifi driver problem, I guess a fast way is to port the MediaTek wifi driver first.

Currently I am making some progress about Makefile, but still can not get compiled mt7628.ko yet. There is a lot of CONFIG define need to be clear first, or it will bring weird trouble. This must be a long way to go.

 include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk


include $(INCLUDE_DIR)/package.mk

    CONFIG_RALINK_MT7628=y \
    CONFIG_MT7628_UAPSD=y \
    CONFIG_MT7628_MAC=y \

include $(INCLUDE_DIR)/package.mk


define KernelPackage/mt7628-wifi
  TITLE:=MTK MT7628 WiFi Driver
  AUTOLOAD:=$(call AutoLoad,98,mt7628)

define Build/Compile
$(MAKE) -C "$(LINUX_DIR)" \
SUBDIRS="$(PKG_BUILD_DIR)/mt7628_wifi_ap" \
M="$(PKG_BUILD_DIR)/mt7628_wifi_ap" \

$(eval $(call KernelPackage,mt7628-wifi))

A simple explain of the Makefile. First from start to “include package.mk” just declare the package download path. PKG_CONFIG_DEPENDS is the real driver configure, this should be done in menuconfig, but for simple, I put it into Makefile. TAR_CMD is a modify version of tar, or when you compile openwrt will complain source code path is not correct. “define KernelPackage/mt7628-wifi” to “endef” is used to show this driver in openwrt menuconfig.

The most important one is “define Build/Compile”, this block is the command used to compile Linux kernel driver, we use the PKG_CONFIG_DEPENDS here. Actually you can directly change every marco in this command line to real path and file, then it can directly work in command line.

Screen: Unique ID

In order to indicate every vocore screen connect to the computer, we have two ways:

  1. use USB physics port, but once screen unplug and plug to other USB port, this id will change.
  2. save a unique id into firmware, so every time we can read it from firmware, it will not change.

The second way maybe better for indicate different screens, so for new screens, we will have a unique id store into flash. ID takes 8byte, like B8D8-C876-CC123456, it is alloced in factory production process.

For old driver board do not have unique id, we need to write a unique id to it.

I write a simple tool to read and write unique id from driver board. Download link http://vonger.cn/misc/screen/screen_uid.20210907.zip

It has source code inside. For Linux and MacOS, please call gcc screen_uid.c -o screen_uid -lusb-1.0 to get the executable application.

Run screen_uid.exe, it will show the screen it detected.

Find screen at USB physics port 3
1: Type: 4inch, 480x800x16, TOSHIBA-2122
id: 0000-0000-00000000

choose a screen by index to set random id(1~1, other cancel): 

PS: if no id in the firmware, id part will be 0000-0000-00000000 or ffff-ffff-ffffffff

Input id 1 to modify first screen in the list, then a random id will write to it.

After that we have alloc a new random id to the screen.

Find screen at USB physics port 3
1: Type: 4inch, 480x800x16, TOSHIBA-2122
id: ef00-4900-f1aede55

Next time run, we will find it has a new id, and if you do not want to modify it, directly press return/enter button to quit the write id process.

Screen: hardware upgrade

We are going to have first big hardware upgrade for the driver board. Upgrade from version v7a to v7b and v10a to v10b.

New features and changes:

  1. increase backlight brightness, from approx. 300lu to 400lu.
  2. fit new version 4.3inch screen and later possible new model 4inch screen.
  3. increase stable, solder protect diode directly on board.
  4. increase stable, add write protect signal to eeprom to avoid software mistake write.
  5. change SMT pad size and shape for easy mount on other PCB board.
  6. change SMT pad silkscreen text from “+”, “-” to “DP”, “DM”.
  7. change 8p FPC connector to increase its usage life time.
  8. v10b use purple PCB to avoid confuse with green PCB v7b.
  9. PCB board thickness from 0.8mm to 1mm, increase physics strength.
  10. other small changes to increase USB stable and lower power consume.

Expect new driver boards will come at early of Sep 🙂

Screen: Glass is really easy to break…

Recently we get report about some screens are broken. The bad one looks like this:

It shows some unexpected line on screen. When we get the returned screen, and find its driver chip is broken…

From the picture, I find its inside chip is so thin, and looks like made by glass, I think it should be Silicon, used to driver every line on the screen 🙂

For DIYer, please be very careful when install this part, only 0.2mm so it can not stand any force. We will also be very careful when package them.

Screen: 4inch Increase Backlight Brightness

Because current 4inch screen(based on driver board v10a) is designed for very low power usage and intend to be long life time, so we have to limit its backlight brightness to save power. But currently maybe people do not care about the power usage and backlight lifetime, so I write this blog to provide a solution.

v10a driver board has a 1210 size resistor, normally on its top marked 20R0 or 200. It is 20ohm resistor(red arrow).

v10a version

Change that 20ohm resistor to 1ohm resistor will be able to make it brightness to max, and its output current will be 160mA. Do not use smaller than 1ohm resistor, backlight will burn in a short time… and do not ask me how I know that. :’) 160mA should be its max safe current for 1~2 year usage — I did not test.

After the modify, it will be much brighter than the original version. But any magic has a cost, this will reduce 75% LED life time and much increase power consume, the driver board will become pretty hot, from my test, increase around 15C, current consume from 0.12w to 0.25w.

PS: this modification is not easy for beginner, need a hot air gun and some glue, if action not careful enough, might melt the connector, DIY is always dangerous, be careful 🙂

5inch(v7a) also has a way to increase brightness, need to change one resistor from 10ohm to 5ohm to double its current. From my test, it do not have big difference, not worth to do the change.

Chip Price is Crazy…

Recently chip price is even crazy. Our screen main chip price increased 60%…and screen driver chip price increased 100%.

We have to increase VoCore2 4inch Screen price from 35.99USD to 37.99USD, 5inch Screen from 52.99USD to 53.99USD in order to cover the crazy increased cost more or less.

We promise once chip price back to normal, we will reduce the price to normal too. Sorry about this, hopefully this crazy chip shortage will end soon.

Screen: Windows + Simhub

Update 20220604: Please use zadig to install libusb driver, new tutorial here http://vonger.cn/?p=15204 or use WinUSB driver from SimHub. They are much stable than libusbK driver.

Recently everyday we get a lot of emails about screen can not work after USB plugin. I have to write this tutorial as people said there is no tutorial …

PS: I think this should be Simhub developer job? 🙂

First of first, plugin the microUSB cable to screen and another side to the computer. VoCore Screen requires a very good USB cable, because it will send data at max USB 2.0 speed, over 300MHz, even faster than most DDR data line.

You will find the screen in your device manager, means it is connected.

USB2.0 Screen is our VoCore Screen

Next, let’s install its driver. Download it here: http://vonger.cn/misc/screen/v2touch-win64.zip

run InstallDriver.exe

Uncompress the zip file, and run InstallDriver.exe in its driver folder.

a few seconds, install completed

After install completed, you will find the device is working now. Under libusbK Usb Device => USB2.0 Screen

Test, now everything is ready, we can run screen_test.exe in the driver package, check if the screen is able to show something, also screen_test can be used to check if touch screen is working normal.

Final, run SimHub

You will need to enable VoCore Screen first.

Click on Dashboard => VoCore => Enable display, once it shows connected, in a few seconds you will see the dashboard show in VoCore Screen.

Here is my display, works well.

Screen: Check Broken and Repair

Recently I get around 10pcs broken ones returned. Is it really the mystery ESD problem or something else? Let’s analyze one by one check what is the problem. Hopefully this blog will also help DIYer find a way to solve such problem.

some broken screens.

1.Obvious physics broken ones:

Four screens has such problem. Red rectangle area is the weak point.

Left FPC 51p is for screen and right 8p is for touch screen. From the picture, the 51p and 8p both tear off by force. FPC is something like tape, it is afraid of sharp edge. Such problem normally happens when you bend the FPC hard, and FPC touch the PCB or the connector edge, it will be easily broken.

Recommend: FPC better to have a beautiful round corner, this will reduce tear off chance, also use the bubble tape around 1mm to stick it to PCB or back, NOT recommend use the hot melt adhesive, it is bad to fix the PCB because there are so less margin after it becomes solid, that will cause it easy to broken FPC.

2. Hidden Physics Broken

This screen problem is when we run test application send_frame frame.dat, its backlight will not able to turn on. One of broken screen is such problem. After remove its touch screen, I find the FPC is normal, but the liquid crystal driver chip is shattered. That driver chip is like a very thin glass, and when people is trying to force the glue on FPC off its holder, it will have very high chance to broken that chip.

PS: this part debug is a pain, last year on another project we use this screen, around 20pcs broken because of such problem, workers mistake stick the bubble tape to this area so when we remove the screen to repair other parts the screen broken by the force.

Recommend: tape or adhesive leave far away from this area! Do not touch this FPC at install. New version screen do not have such problem, but we still suggestion do not put any tape or adhesive on the FPC area, it should be only on the steel part.

3. Not Well Connected

adhesive inside connector, caused it not well connected.

One broken because of this reason, this screen also has FPC tear off problem.

Recommend: please do not use adhesive… 🙁

4. Firmware Problem

Rest screens are all such problem. This problem I never expected. That just is the unknown device problem. This should not happen if the screen is operated normally, I guess maybe some client side code has bug, I will check with SimHub developer.

For my MacOS or Linux, we have lsusb command, it will show the device like this:

Bus 020 Device 005: ID 04b4:8613 Cypress Semiconductor Vendor-Specific Device

If firmware is normal, it should be like this:

Bus 020 Device 011: ID c872:1004 c872 USB2.0 Screen

The firmware is written in EEPROM, and it should never lost any data unless client side application write something wrong to it…This is very weird.

I attached the firmware loader(download here), this application only run in MacOS.

For PCB version v05 and v07a, please call

./eeprom w ./FW200502-4IN14V.bin

For PCB version v10a, please call

./eeprom w ./FW210105-4IN3V3

After firmware upload completed, disconnect and reconnect the USB cable, all of the screens has such problem are fixed.

So the final result, none of the driver board are really broken 🙂 Just the physics broken screen we can not fix have to change screen. All 10 of them are repaired.

5. USB cable problem

This is not belong to this part but also very important, please use a short or well covered USB cable. This screen used max USB speed, every data line is 480MHz, so a bad quality USB cable will not make it work, will cause sometimes the screen can not be recognized or show some random noise on the screen. We also think the firmware is broken by this way. This need to be confirm.