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.
Now we can find the define: -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 …
Compare Makefile, we can get the defines. Update Makefile…
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:
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
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.
In order to indicate every vocore screen connect to the computer, we have two ways:
use USB physics port, but once screen unplug and plug to other USB port, this id will change.
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.
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).
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.
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.
Next, let’s install its driver. Download it here: http://vonger.cn/misc/screen/v2touch-win64.zip
Uncompress the zip file, and run InstallDriver.exe in its driver folder.
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.
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.
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
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.