jock
-
Posts
2159 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
You're right, the IR kernel module is not enabled in legacy kernel. This is a mistake I will correct as soon as I can.
It works fine on mainline kernel though. Since most of the remotes shipped with rk3229 boxes uses the NEC protocol, you can probably successfully test it running ir-keytable -p NEC -t and pressing the remote keys.
I tested Lima driver on 5.7 and 5.8, but performance is always the same. The kernel driver is only a small part of the whole, most of the important code is in Mesa project, which contains the actual OpenGL implementation for the Mali-400, so until Mesa is updated to the latest stable version in Ubuntu/Debian or you compile the latest development Mesa, you won't see any real progress.
By the way, I think that the Lima driver is not yet very well optimized yet, there is some bottleneck somewhere that makes it work so slowly in X.org. I also tried Gnome 3 on a poor rk3228a (kernel 5.6) and, incredibly, it seems to work a bit better than xfce. It is still slow, but at least has a rich graphics and does not stutter like xfce do.
As the Mesa developer said also in the issue regarding the slow performance of the Allwinner A20, modesetting x.org driver seems not to be really friendly with Lima driver and, in general, with embedded graphics. Panfrost suffers too, for example, and is not so snappier as it used to be with armsoc.
I didn't try armsoc yet, I don't even know if it could work or not: actually the kernel is not involved in compiling armsoc, since it only interacts with the DRM bits via "dumb buffers", but I'm skeptic about its interaction with lima driver. You should try to force it using /dev/dri/card0 using some xorg.conf option (DRICard maybe, but man armsoc could help you) and see what happens: if it works (eg: fast 2D) probably you won't be able to use hardware acceleration for 3d games.
Lastly, the armsoc driver packaged with armbian is an old one that does not use generic dumb buffers, but instead specific IOCTLs and works only on some DRM drivers found in very old kernels. Don't use it.
Ah, a last note... I have an AmLogic S905 box around here too, it has Mali-450 GPU, which is much faster than Mali-400, and also faster DDR3 memory. There Lima driver works much better for 2D out of the box, but still I have the feeling it is not perfectly fluid and optimized as it should be.
-
11 hours ago, nokirunner said:
@jock From what I have investigated, I don't think it's a question of SOC performance, I think the driver especially the kernel side dri rockchip is badly built at some point. It should take care of the management of the hdmi and of the video buffering and little more and it is evident that it is poorly managed, so much so that when we put card1 instead of card0 it becomes 2D fast but the hdmi loses the management of the monitor resolutions, and even in the "very slow" mode with card0 the resolution management of the monitor works only to a limited extent (many resolutions are missing) it may also be that in the latest kernel these problems have already been solved, I noticed that these drivers, both on the kernel side and on the mesa are heavy developed. Looking at the git of the rockchip dri kernel you see there are a lot of changes in the last few months, i would be curious to see if the upcoming kernel 5.9 has fixed these known problems.
this mesa issue about Lima seems very similar to what we are experiencing: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3033
-
21 hours ago, nokirunner said:
@jock right now i'm trying to understand each other better, apparently, lima is just "the rederer" every producer then has his own drivers or something like that .. in our case it should be rockchip ... i'm just investigating right now
https://gitlab.freedesktop.org/lima/web
above in the wiki :
edit: the display drivers it could be these:
https://github.com/rockchip-linux/libmali
which appears to have been updated to work with mesa 20.1.5 APIs... which as far as I understand are the blobs updated to work with the new mesa
Yes every manufacturer has its own 2D hardware, Lima handles the Mali graphics which is 3D only; but when you use X.org with modesetting driver, it uses glamor desktop acceleration, which in turn doesn't use the 2D hardware but uses OpenGL to accelerate the desktop. Confused?
I am. In my opinion X.org people choose this way to handle things and we have a driver (modesetting) that works with many OpenGL drivers, but with suboptimal performance because bad 3D is used (Mali 400 is the poorest GPU on the ARM market today) in place of good dedicated 2D hardware.
I tried also the suggested xorg.conf options, and the X.org server started correctly with hardware acceleration, but I didn't notice any particular performance benefit.
I would be happy to get the same performance as kernel 4.4 with armsoc, but at the moment it seems that Lima just can't afford that.
Note: you can still run the proprietary Mali stack (kernel driver + opengl userland libraries) and Armsoc on kernel 5.6, but you have to compile the kernel driver yourself and still they have limitations (no OpenGL driver, just OpenGL ES)
-
8 minutes ago, xwiggen said:
I've installed images from download page (bother buster linux 4, focal linux 4) and installed them to eMMC with multitool. They boot nicely and are stable.
I did use the libreElec dtb file, then the alternating led flashing red/blue went away and blue stayed on.
Right now after testing some days, I can't boot libreElec from SD or eMMC (which worked ok previously, with erasing flash thru multitool), also adding dtb now leaves me with an unbootable system
??
I can flash with multitool one of the stable images. If i select RK3228A, RK3228B or RK3229 and reboot, I get a message that UUID=.... not found and drops to an initramfs prompt.
really weird.
I don't understand exactly what you mean when you say "libreelec dtb" and adding "dtb"...
Newer images (like those in the armbian download page) use device tree overlays, so you don't have to substitute or handle dtb files manually.
Did you try to follow my suggestion to run rk322x-config, don't reboot yet but remove emmc string from overlays in /boot/armbianEnv.txt and then reboot?
-
1 hour ago, nokirunner said:
Guys, I have something new, I don't know if it's only valid on my device or if it concerns others.
With the Armbian image 20.08.0 - Ubuntu Focal Desktop - Mainline kernel 5.6.19 which contains the LIMA open source video drivers I found that the default configuration the acceleration does not work. these socs have two videocard card0 and card1, on my xorg configuration card0 was set, it worked in the sense that the desktop started but the video acceleration was bad. I changed this setting to card1 and voilà the acceleration is activated as it should.
the file to edit is this: /etc/X11/xorg.conf.d/40-serverflags.conf
change card0 with card1
Section "ServerFlags" Option "AutoAddGPU" "off" EndSection Section "Device" Identifier "meson" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" #card1 now is good EndSection
My device is a scishion-v88 I don't know if it is a problem that only concerned my device or is it a much more general problem, in the meantime I have reported it, in case other devices are afflicted by the same problem with the LIMA drivers.
@jock I tried to activate the wifi ssv6x5x drivers on the 5.6 kernel but I couldn't, are the new drivers working on the legacy kernel also compatible with the 5.6 kernel?Dunno, on my setup if I left card0 I get hardware acceleration and glxinfo/es2_info show me that lima driver is in use, but desktop experience is not so great and the cursor is often flashing.
If I use card1 the desktop experience is better, but there is not hardware acceleration and glxinfo/es2_info show me llvmpipe, which is software renderer.
I think Lima driver and mesa bits are just not working very nice with X11, probably they deliver the best experience using wayland-based desktop environments. Don't want to say and heresy, but xfce lately is becoming quite slow, people says lxde is snappier on such hardware.
About ssv6x5x, I did not even try it on mainline kernel, it is a miracle it compiles and works on legacy 4.4
Probably the drivers requires a complete overhaul to work well with mainline kernels.
Its sibling, the ssv6051 driver, has been left behind by rockchip itself in the jump to the 4.19 kernel they recently made. ssv6x5x and ssv6051 are very similar, and both of them are incredibly messy!
-
On 8/18/2020 at 7:22 PM, xwiggen said:
ok, I've got a MXQPro 2G/16G RK3228A which doesn't boot after rk322x-config to either setting. What does work is the rk3228a-box-mxq4kpro.dtb I took from https://github.com/knaerzche/LibreELEC.tv/releases/tag/b7186bc
Hum, can you be more specific on what image you installed, what settings you choose in rk322x-config and about your hardware?
Normally the only setting that can prevent booting is setting eMMC in place of NAND and viceversa.
Also when you select eMMC in rk322x-config it also enables DDR mode which is usually safe but may be a source of troubles.
In such case, you can run rk322x-config and then manually remove the emmc entry from overlays in /boot/armbianEnv.txt and then reboot
-
17 hours ago, hexdump said:
@jock @fabiobassa - to explain the difference between the addresses by the maskrom vs loader mode makes sense ... i think i did this hybrid setup with original initial boot blocks and mainline u-boot back then because i was thinking that this is the only way to get it working with the existing trust image ... where is it actually defined if trust images will be used or not - is it somewhere fused in the hw or is it just a matter of the initial boot blocks? if its just a matter of the boot blocks, then i should even be able to replace the entire boot with something adjusted self compiled maybe ... another reason i did it that way was that shortly before i did something similar for a rk3318 box for which there was no atf i could build myself (rk3328 one did not work) so i had to keep the original initial boot blocks there ...
best wishes - hexdump
I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.
The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:
- the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory
- the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before)
- the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000
- the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries
- the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job
- the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot
- u-boot finally loads the device tree and boots the kernel
when you use prepare the u-boot and trust images with loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).
Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.
The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:
- The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory
- the SoC ROM code reads the u-boot SPL that immediately follows the TPL
- u-boot SPL executes the OPTEE trustos
- u-boot SPL executes the main u-boot
- u-boot loads device tree and boots the kernel
For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.
My guess is that the rk3318/rk3328 boot process is very much the same
-
New Armbian 20.08 Ubuntu Focal Desktop image with kernel 5.8.1, on my box it works pretty fine, but feel free to test it on yours:
https://drive.google.com/file/d/14iUGANr_-Cr3LvAP6wm3K0kLJAveHPhF/view?usp=sharing
-
2 hours ago, Reddwarf said:
Thanks, how can I determine what binary I should use for updating the loader? If I run Cpu-z on the original Android is says that the cpu is a 3028, what is correct?
Never heard about rockchip 3028, it is quite sure you have a rk3328, or maybe the little rk3318 brother.
To be sure, you should read what's printed on the soc itself. There is also this table: https://forum.xda-developers.com/showpost.php?p=56219933&postcount=2 that matches the USB vendor/device ids with the soc. I don't know if it is verified.
Once you got the SoC, you will need the usbplug binary for both the db and ul commands, but this will flash another rockchip proprietary loader, which I don't know it is what you want...
edit: I just read about @hexdump instructions, that's a good recipe on how to compile and install mainline u-boot as a bootloader, but I'm understand it correctly, there is some chain-loading between proprietary u-boot and mainline u-boot. You can customize the boot options and avoid being slave of the rockchip u-boot binaries, but requires manual intervention. I would point out some clarifications: as @fabiobassa once told me, the 0x2000 offset when using rl/wl commands of rkdeveloptool is due to maskrom or loader mode: in maskrom mode there is no offset, so you can write the entire eMMC/NAND. In loader mode the first 0x2000 sectors are hidden, hence the offset.
-
17 hours ago, Micael Illos said:
Hi, I've been trying to find a cheap and effective tv box to run armbian on the eMMc.
I've had a bit of bad luck, I bought the new sunvell r69 H3, and unfortunately it doesn't even have an eMMc it had NAND,
which is basically impossible to run linux on let alone the lack of support for the H3 ( all the support is on the H2).
Next I bought the TX3-mini-p (1g/8g) and that was also a nightmare, the armbian 5. and 4 kernals would not run on it.
Only the 3 kernal would run from the sd card but when I tried to dd the os to the eMMc it bricked the board because the uBoot is very old.
My only requirement is a tv box that has eMMC.
If anyone knows a tv box that is cheap and has eMMc and has armbian images that run on it please reccomend to me.
H3 is very well supported in armbian and linux mainline, but I don't know if there is a NAND driver actually.
The choice of the box vastly depends on what you need to do and how much horsepower you need with that one.
If you want to be sure you get what you actually want, buy a proper SBC with eMMC and a case.
Hardware of tv boxes, expecially cheap ones, is always a lottery, as you already experienced by yourself.
-
12 minutes ago, Reddwarf said:
Yes I have the original Android image and can flash it with the factory tool. But I want to run Armbian and the problem is that the box does not boot from sdcard or usb with the factory bootloader. I'v tried to flash a new bootloader with the rkdeveloptool but the response is "this operation is not supported". If I flash Armbian in the box it does not boot. However, the factory tool is capable of flashing bootloader (I can see it does that while flashing Android), so if there is a way to replace the bootloader aection in the Android image I might be on dry ground.
My hypothesis is that you are in loader mode, so you can upload a firmware update but can't upgrade your loader.
To be able to upgrade the loader also you must be in maskrom mode. To enter maskrom mode you can either gate the clock of the eMMC (via the screwdriver trick of the unbrick section) or run rkdeveloptool rd 3 while in loader mode.
Once you're there, first you have to "download" the loader binary on the soc (that's called usbplug in this stage) to initialize DDR memory and load the basic services of the SoC, and then you can finally upgrade the loader itself (see the rkdeveloptool db and ul commands on the first post on how to restore backups).
You may take a look to this repository for binaries for rk3328
-
@Reddwarf Searching that box through google, I find an RK3328 device. Unfortunately I have no experience with rk3328, but I guess the general rules about rockchip socs probably applies to this one too. You may profit from the first post, specifically from the unbrick section and the rkdeveloptool instructions to make and restore backups/images.
You probably need a male-to-male USB cable to do such low-level tricks, but if you grab the original Android image you can probably be able to restore at least the original functionality.
-
7 hours ago, Roscar Cunanan said:
hey jock,
im trying to build a linux driver for a gigabit ethernet adapter i used for another device into my rk322x armbian build. im on Armbian_20.08.0-trunk_Rk322x-box_buster_legacy_4.4.194_minimal.img.xz because its the only one that works well when flashed in nand. but when i try to build it, the following error is returned (after i imported the headers you provided):
root@omvbox:/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE# make
NOW IN default
KDIR is /lib/modules/4.4.194-rk322x/build
PWD is /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE
make -C /lib/modules/4.4.194-rk322x/build SUBDIRS=/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.194-rk322x'
CC [M] /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE/ax88179_178a.o
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
make[2]: *** [scripts/Makefile.build:284: /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE/ax88179_178a.o] Error 1
make[1]: *** [Makefile:1473: _module_/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.194-rk322x'
make: *** [Makefile:33: default] Error 2
it looks like this issue is architecture related. are you on ubuntu or debian?
Hello,
yeah there are some issues with the kernel headers packaging. In particular, as you noticed, there is a problem with the architecture armhf/arm64.
Everything should work if you first export some compilation variables:
export KSRC=/lib/modules/$(uname -r)/build export CROSS_COMPILE=arm-linux-gnueabihf- export ARCH=arm make -j 4
The ARCH variable should fix your particular problem
-
Update:
Legacy images have been updated with ssv6x5x driver working out of the box.!
The esp8089 driver has been included in the new images, but it still require to manually put the firmware files and wlan-esp8089 device tree overlay in armbianEnv.txt. I will get this tidied up and ready on next release
-
-
On 8/9/2020 at 10:18 PM, jaum20 said:
When do you say dd the .imgs, do you mean to connect the board to a Linux pc and use the dd command?
You can use the multitool to dd image files directly on the device: it has a fully functional bash shell to do such kind of maintenance tasks. Nonetheless you need to do know what you are doing.
Maybe you can burn the "bad" backup you made and then burn the rootfs from the image @fabiobassa provided. You need to do some juggling with the original image, but if you are able to do so you can try.
Your board is a new revision of the r329q family. In alternative you may have more luck tryingr other images for boards which are older r329q revisions (v2.0, v3.0, v7.0, ...)
-
18 minutes ago, Rajesh said:
The source code of the driver is available from https://github.com/jwrdegoede/esp8089
The patch form to directly paste the driver into the 4.4.194 rockchip kernel tree is available here
-
There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.
What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).
As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.
Device trees describe the hardware equipment of your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.
All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.
Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.
-
On 8/3/2020 at 7:17 PM, victroniko said:
About /etc/modprobe.d/esp8089.conf - already gone, first tests were done on 20.05.6, after the wipe I mentioned earlier i'm on 20.08.0 now. What I do find strange, is that relying on default setting does not work. Passing the crystal_26M_en=0 parameter did the trick, on this board at least... Every test was with an inmediate power off-on cycle instead of a reboot, to discard possible quirks from the already initialized (firmware loaded) ESP8089 chip.
Ok, that's interesting, you can then to put options esp8089 crystal_26M_en=0 in /etc/modprobe.d/esp8089.conf to see if it works like being modprobed manually. I'll definitely add this conf file in the final distribution.
On 8/3/2020 at 7:17 PM, victroniko said:offtopic. I said I don't know C/C++, that's true... But I did some things in VB6 many years ago, it's not as if I saw modern code and felt totally lost.. And my day-job is electronics so I understand quite a bit how microcontrollers work
Doing some research about the es8089, it turns out that it is nothing different than an esp8266 with less pins and interfaces. esp8266 is a very cheap and flexible microcontroller that is pretty assimilated as "the arduino with wifi". Some people attached the esp8266 modules to sdio pins of raspberry pi zero to gain wifi and this esp8089 driver module is the software part to make it work: https://hackaday.com/2016/04/21/usb-less-wifi-for-the-pi-zero/
15 hours ago, Rajesh said:Just wondering if this will also work on ARMv8 64 bit boards? Probably not, but if there is a similar solution for this on other boards it would be great!
Usually kernel driver source code is happy to compile on both 32 and 64 bit modes without any modification, so there good chances it will!
-
Glad to hear progress! I'm sorry I pointed you to use crystal_26M_en=2, but that was because all the rk322x boxes I have seen use a 24Mhz crystal, so I thought the same was for yours. I first checked on the pictures you provided, but the crystal was totally unreadable.
If you created /etc/modprobe.d/esp8089.conf file (as I suggested you in this other post), remove it. Also unblacklist the esp8089 module and reboot.
From what I see from source code, the 40Mhz crystal is the default when no options are passed to the kernel module.
I prepared this other kernel module: esp8089.nop2p.ko I blindly changed a couple of source code lines to avoid the p2p0 interface creation. I don't know if this works, but you may give it a chance. Overwrite the existing esp8089.ko with this one and reboot to see if it has any effect...
For the issue about the media framework, I'll take a look into it...
-
2 hours ago, jaum20 said:
What information do you need?
My board us "R3229Q _V8.0". I was using LibreELEC-RK322x.arm-9.2-devel-20200427213119-b7186bc-rk3228a-mxq4kpro.img.gz flawlessly on a 4g Toshiba sd. I downloaded the image Armbian_20.05.6_Rk322x-box_focal_legacy_4.4.194_desktop.img.xz and followed the instructions of the first post for install on eMMC. I used a 32gb Samsung SD. Everything succeeded with no problems
When I connect the board to the power with the LibreELEC sd inserted it doesn't boot anymore. The blue led is on but no output from HDMI.
If I remove the sd, Armbian boots form internal storage with not problem.
Ok much better, but at the moment I have no idea this is happening.
The libreelec boot is somehow engaged because the behaviour changes if you leave the sdcard into, but the reason why it hangs is not clear to me yet.
I will try to replicate soon on a board of mine
edit: @jaum20 problem solved! Long story short: substitute the file rk3228a-box-mxq4kpro.dtb in the root of the libreelec sdcard with the one attached here. Important: if you're going to update/upgrade LibreELEC, you will need to replace again this file. This is a "problem" I will likely ask to @knaerzche if it can be solved somehow.
Detailed answer for experts: the device tree with the legacy kernel is missing the property arm,cpu-registers-not-fw-configured in the timer section. It is needed on armbian but it is not needed on Libreelec because armbian has OPTEE as trust os (which requires the property), instead Libreelec uses the proprietary u-boot and trust os (which does the timer initialization by itself).
-
21 hours ago, jaum20 said:
I followed the instructions to install to eMMC and everything worked as expected. The problem is that now the box can't boot my LibreELEC sd. Any ideas ?
Normally everything which is in the SD card has priority, but if you don't give details it is very difficult to have ideas
-
Good news, expecially for @nokirunner and @DaviMesquita
Finally we managed to make the ssv6x5x driver work on the ssv6256p chipset and it turns out the it is also working pretty well. I removed most of the logging messages it was spamming on the dmesg log, now it is much more silent and it is ok this way. Teaming with @fabiobassa we optimized performances quite a bit, so expect ~60 Mbit/s at least on optimal setups. It works on both 2.4Ghz and 5Ghz bands.
The driver will be included in the armbian images soon, but in the meantime anyone can test it.
- Download ssv6x5x.koand put it into /lib/modules/$(uname -r)/kernel/drivers/net/wireless
- Download ssv6x5x-wifi.cfgand put it into /lib/firmware
- Download ssv6x5x-sw.bin and put it into /lib/firmware
- Run depmod -a
- Add blacklist ssv6051 in /etc/modprobe.d/blacklist-rk322x-box.conf (ssv6051 and ssv6x5x kernel modules clashes, we need to blacklist ssv6051 for the other to work)
- Reboot!
Any testing report is appreciated!
-
I see promising results, very well!
"queuing unknown CIS tuple" are not really errors, you can safely ignore them.
For what I know, p2p0 and wlan0 interfaces appears with most of these android-derived wifi drivers.
I have some boards with ssv6051 wifi chip and I have to connect using p2p0 interface because wlan0 always crashes kernel, don't know really why, I never spent time into.
About the autoloading of the esp8089 module at startup, you can create a file in /etc/modprobe.d/esp8089.conf and put this content into:
options esp8089 crystal_26M_en=2
so when the module is autoloaded, it is also given the appropriate module parameter.
As another hint, to test the firmwares and things avoid the Network Manager. It is slow and has latency, and does not always reacts immediately. Use the command line tools to scan the networks, for example (always use sudo, or do it as superadmin, otherwise you get cached data):
sudo iwlist wlan0 scan
You may also scan the p2p0 interface and see what changes. Usually you won't get more than 10-12 access points in the list.
I could not find any evidence in the source code that the files should be placed in esp8089 subdirectory, so I'm not totally convinced about the firmware placement in /lib/firmware/esp8089. Double check that this is really what the kernel module wants: loading the kernel module and doing a successful scan should be enough. Every kernel module developer decides where the files are put, some wants their own subdirectory, some others don't. dmesg should tell you if the firmware was in the right position or not, always read its output very carefully!
Once you get sane and predictable results with iwlist, you may proceed to use the Network Manager to connect to a network. From the command line you can also use the handy nmtui tool
Always reboot between tests, even though I read that rmmod (prefer modprobe -r to unload a module, anyway) crashes the kernel and freezes the system, so there is no other chance
Good luck!
CSC Armbian for RK322x TV box boards
in Rockchip CPU Boxes
Posted
That's the DRM driver built in the kernel. I'm no expert in DRM matter, but this is the general idea I made up: the 3d chip (Mali) can't access the 2D framebuffer; the SoC instead can, precisely on rockchip SoCs it is the VOP that has access to it. With "MatchDriver" configuration line you tell the modesetting driver that it has to connect to the rockchip DRM in the kernel.
Since the DRM interface is pretty standard among various SoCs on recent mainline kernels, it does not really matter. If you take a look to the armsoc source code (my variant), you will see that the Allwinner (sunxi), Rockchip and AmLogic DRM (meson) interfaces and they are exactly the same code: I copy-pasted and it just works, only the DRM name to connect to changes, but the core code of armsoc uses the standard dumb buffers DRM interface from the kernel.
Modesetting does the same thing to connect to the kernel DRM, you may optionally tell it which is the DRM to connect to (or the "card").
As @usual user also said, the general slowness comes from the glamor "acceleration", which uses the Mali 3D OpenGL for 2D things, instead of leverage the DRM things for 2D.
I suspect that if you disable the glamor acceleration for modesetting with:
you end up with decent 2D and no 3D: modesetting will behave like armsoc for 2D, but differently from armsoc, it will totally ignore the 3D part. (hint: you may have to change card1 to card0 on your box)