Now we have screen 🙂 So I’d like to port Qt. Thanks to pawelkn, https://github.com/pawelkn/qt5-openwrt-package, this package works well, just need to add one line. I search google, this is because MIPS do not have 64bit atomic operation, so we need to use the library to simulate it.

Put this Makefile and other files to openwrt/package, then make menuconfig, in Library -> Qt5, select qt5-core, make V=s

Compile is smooth and take a long time…After upgrade, also make the example file and copy to VoCore2.

Like usual, it is not work at first time, the screen part only. 🙂

This is necessary: export QT_QPA_PLATFORM=linuxfb:fb=/dev/fb0
We must use this command setup framebuffer device.

I do not know why it not work, possible reasons:

1. Qt support DRM but not framebuffer anymore, need to check linuxfb plugin for Qt5.
2. My framebuffer driver has bug, that block the demo runs on the screen.
3. VoCore2 do not fast enough for Qt(this is not likely, because I can find it actually works, but just stopped at somewhere, looks like it is wait for some device ready)
4. Other necessary device such as keyboard, mouse block the process.

From my first test, I guess Qt application bootup on VoCore2 is pretty fast. It takes around three seconds to start, just eat a lot of memory, demo consume around 22MB memory, maybe it can not work on vocore2 lite which free memory only around 30MB.

Also I port Qt5.11.3, here is the link: http://vonger.cn/misc/vocore2/qt5.11.3-openwrt.zip

This blog do not have any tech included. Just want to write down something to boost myself, I need to spend more time on it because the screen is still need a lot polishing.

First of all, I need to imply all drivers to kernel level. My demo just show the result, actually I did a lot of prepare before that, it is not plugin and play yet.

And Christmas is near, I do not have much out-source work for now, so I can focus on this screen. I will try my best to finish it before that holiday.

Next step, I am going to port FC games simulator or dos games simulator(except DOOM, not a challenge for me anymore 🙂 after this and with exists sound support, VoCore will like a real small computer.

Maybe before step two, another good choice is to port X-window system to VoCore2(with a SD card for more storage). As I know a lot of desktop linux is able to run in 128MB memory(even 64MB, very old computer). If I can do optimize on it, it should be no problem to run on VoCore2.

This is also a tech prepare for VoCore3.

PS: VoCore3 still have a long way to go. I need its solution price lower enough, power consume lower enough, also tons of interfaces. VoCore2 is the best choice in the market as I know and for further two year it should be. Anyway, VoCore2 will keep production, nearly ten years should no such worry 🙂

PSS: I know USB2.0 screen is kind of out-of-date, if we do screen in USB3.0, it should be pretty easy. I spend almost one year and a lot of money to finish it has three reasons:

1. USB 3.0 power consume is super high. Of course, you can not let 10GHz bus eat only a little power.
2. USB 2.0 is common and compatible with USB3.0, so for small screen, it is good enough in most situation.
3. USB 3.0 supported chip is very expansive for now, everybody like cheap but fantastic production, so any unnecessary cost is a waste.
3.1 VoCore and RaspberryPi do not support USB3.0.
no reason four. 🙂

After this simple fix, now I have make fbcon works on VoCore2 and its small display.
Here is the picture:

This driver will map /dev/fb0 and we can easily control it as framebuffer, fbcon need to select from kernel, then it will automatically bind to /dev/tty0. We can use command “/bin/ash –login > /dev/tty0 2>&1” to redirect serial port input/output to the display.

After that, we can get output from the little display.

Next blog, I will try to make it easy to use and public every steps of how to use it.
Later I will public most of its source code to help you easy hack 🙂

The mysterious bug is this driver crashed at par->interface = interface; and after debug, par is a null pointer, but info is not a null pointer! Let’s check framebuffer_alloc source code, if return info is correct, there is no way par to be null pointer.

Also step into this framebuffer_alloc function, in this function info->par is not null and its value is correct. So what is happening once info returned? who changed info->par to null? This is really weird bug…I have never seen such thing before.

PS: I guess I find the problem. If I put the source into Linux source code, it will report some .ko is missing, but if I move it to package/kernel as a package, it will happen that weird problem. So it is package missing problem.

After many weeks struggle, finally I finish the new firmware for the screen, this new firmware mainly improve the boot up speed of the screen, old one takes six seconds, new ones less than one. Also add control function to modify backlight strength and support 8bit/16bit/24bit pixel format.

Based on this firmware, now we can have:

1. Linux text console which is based on frame buffer 16bit or 32bit, old firmware only support 24bit.

2. super smooth games from GBA, NES, GEONEO. We support 8bit mode, now we have more CPU for game logic but not for screen data transfer.

3. smooth games from DOS. DOS games such as DOOM will be faster, such game 12fps is playable, new firmware will make it at least 15fps.

4. control rotate the screen, backlight.

The main optimize is for VoCore2 or other embed device with USB port but no display port such as HDMI. This solution will greatly save cost. For example, a chip with display port normally is over 5USD, it is not included DDR and flash yet, full solution with wifi, ethernet should be around 35USD, a screen with HDMI is around 25USD. So mass production is 60USD/pcs 10K unit.

For VoCore2 solution, only 33.99 + 17.99 = 52USD, this is just sample price! 🙂 mass production(1K unit) normally have 40% discount, totally cost should be around 30USD, only half!

What you will get for 30USD? 580MHz Linux based computer + 5 x 100Mbps ethernet + 150Mbps wifi + smooth UI display. It is fit for the control system, education toy solution for kids, also a good replace STM32 or RaspberryPi.

Linux console driver will be released in next week, need more hard work, I am enjoying it 🙂

Combine VoCore2 Ultimate firmware to latest openwrt is always one of my dream. Today I start first step.

VoCore2 ultimate has one driver is different than the single board version, it is ES8388 codec driver, but limited to my patch skill, it is so hard for me to patch it to openwrt system. After port mediatek wireless driver, I understand some of the secret now, so I can push the first version of es8388 driver to github/vonger/vocore2.

Compose

this patch has four files, 810,811 used to patch linux kernel, put it into openwrt/target/linux/ramips/patch 4.14/ then it should work. 811 is used to fix pinctrl driver, because refclk this name has used in many places, if we do not change the name, it will conflict with function named refclk. This patch I will try to submit to openwrt later, it is a bug. 🙂

rest is dts, VOCORE2.dtsi I change refclk pinmux from gpio to gpio refclk, so gpio0 pin will work as 12MHz clock.

PS: gpio0 is not real GPIO 0, it is actually GPIO 11 in register, nobody knows why ralink engineer named it gpio0, you can check its datasheet, really mess :p

How to use?

after patch everything and use the new dts then compile and flash to V2U(a lot of work), you can now try it.

But as I said, this is not a stable driver…es8388 driver is acting weird because I am a noob of alsa. I have to left some back door for hack. 🙂

in /sys/devices/platform/i2c-gpio/i2c-0/0-0010/ there are two file node named i2cread and i2cwrite, used to directly write to es8388 i2c driver and control the codec directly.

Before you use aplay xxx.wav play some sound, please run this command:

first four lines are used to fix the wired bug, maybe my dts sound path setting is not correct cause this problem…(but everything looks correct for me)
second four lines are used to set the volume of left channel/right channel to max, careful your ear! 🙂

PSS: second four lines because I can not find a way to raise volume in aplay, in madplay volume works normal, if you use madplay, ignore those four lines.