Gabor Hidvegi

Of course, I will, but I'm far from that. Most probably it would be faster if I shared the kernel file, that would render all available 2G IoT images usable. I will see what I can do. Unfortunately I couldn't make the sound card work yet, and on my device the touch screen stopped to respond. I ordered another one from Aliexpress, but it will take a few weeks to arrive. I also discovered that the full size USB port is running at 10 mbps normally, because the modem needs to initialize the micro USB port first, and this procedure takes about six seconds. If we start to load the kernel USB drivers after this, then our USB works at 480 mbps. I have to figure out how to deal with it.

The WiFi seems to be okay (not too fast though), the sound card doesn't work under Linux, because it's driver is not finished (like the framebuffer driver), it has only enough functionality to work under Android.

So, I managed to make usable the framebuffer driver under Linux. It's still far from perfect, and the refresh rate is now five frames per second, but of course I can increase it, it's just not necessary yet. On the first picture there is the console I used with an attached keyboard, on the second picture there is a light Window Manager (JWM) I compiled on the machine running with an attached mouse. The distribution is Armbian 5.27, which I found somewhere on the net. The USB port is a budget one, according to the kernel message it doesn't support USB hubs, but I have to try that out yet. Theoretically it is possible to integrate the framebuffer driver into the Linux Kernel's FBTFT subtree, that way it could be more easily ported to mainline. I wonder if I can make usable the WiFi driver along with the sound card.

I managed to draw on the screen under Linux by playing with the driver. It's far from working, but at least now I understand a few things. Now it only refreshes the screen when the FrameBuffer fb_pan_display() function is called, which does a full refresh. It gives no sign of life when only a portion of the screen should be redrawn, like the cursor. I couldn't yet figure out how to detect when the framebuffer memory changes.

Hello all, I bought this nice little board, and after a few hours I managed it to work. When booting from mmc, how is it possible to see the flash partitions (/dev/mtdX)? Do I have to recompile the kernel (5.2), or edit the dtb file, or both?

The "official" LCD works with the device under Android for sure. https://www.aliexpress.com/item/32816194245.html I compiled the Android kernel separately, and used it with Linux (I had to add devtmpfs configuration options), but with the same results, after it turns on, the Framebuffer driver cannot draw on it.

The USB A port with the original kernel is pretty slow, I plugged in a 10/100 MCS7830 Ethernet adapter, and the average up/download speed is around 400 KB/s. I took a look at the code and in kernel/drivers/usb/musb/rda.c I found the following in the rda_start_host() function: /* disable high speed when host*/ power = musb_readb(regs, MUSB_POWER); power &= ~MUSB_POWER_HSENAB; musb_writeb(regs, MUSB_POWER, power); I commented it out, rebuilt the kernel, and now I'm testing whether the USB is reliable or not. The download speed from the board with SSH is now around 1 MB/s.

Hello all, I bought one of these nice little devices, and and after a week of playing with it, I'm quite satisfied. Of course the software side is not the best, but the board itself is powerful, cheap, and it is full of features. Right now all I am missing is a working LCD under Linux. I bought the official phone display from Aliexpress, it works under Android, but no success so far in Linux. So I'm looking for some help here with it. I have cleaned and formatted the kernel source code (kernel/drivers/video/rda directory), it uses and registers the ILI9806g_mcu according to the dmesg output, but there is only garbage on the screen after it is initialized. So I think the FrameBuffer driver maps to a wrong RAM address. The rda-fb module outputs this: "rda-fb rda-fb: init done, 480 x 800 = 1540096, at cf028000, phys 0x8e200000" When I convert the 0x8e200000 to decimal, it is an insanely high number (around 2 terabytes), which is suspicious. Is there anyone here with kernel and LCD programming experience, who could help me with sorting this out? I also tried to compile a kernel from the released Android source code, which is a bit different, but it doesn't work either. My next project is to make working the Vivante driver, also found in the Android source.