usual user

Everything is as expected. - modesetting doesn't have 2D acceleration, but 3D hardware acceleration support over glamour. - fbdev has some 2d acceleration via KMS frambuffer emulation, but no 3d hardware acceleration support. - armsoc seems to have no real 2d acceleration support and no 3d acceleration as I see no suitable sub module. Wayland can use full KMS and 3d acceleration. E.g. Weston with the the drm-backend is running full accelerated. For example, to get a similar flow with Xwindow, armsoc must receive adequate KMS acceleration support and a sub module for 3D acceleration. But there is not much development for ddx drivers anymore. Every new development is Wayland focused. Think it's time to look for a suitable Waland compositor. glmark2-es2-wayland.logglmark2-es2-Xwindow.log

Here my log analysis. Xorg.0_driver_as_modesetting.log: The Section "OutputClass" finds the rockchip KMS device and identifies the card node. [ 31.046] (**) OutputClass "dwhdmi-rockchip" setting /dev/dri/card0 as PrimaryGPU No Section "Device" Identifier "KMS-1" Driver "modesetting" EndSection so driver auto probing with modesetting and fbdev. [ 31.206] (II) LoadModule: "modesetting" [ 31.214] (II) LoadModule: "fbdev" modesetting initializes with KMS device and glamor is loading. [ 31.262] (II) modeset(0): using drv /dev/dri/card0 [ 31.285] (II) Loading sub module "glamoregl" glamor is associating with GPU device [ 36.175] (II) modeset(0): glamor X acceleration enabled on Mali400 fbdev gets unloaded. [ 36.195] (II) UnloadModule: "fbdev" All is set up properly and Xwindow is working as best as possibly with modesetting. modesetting does not use acceleration functions from KMS by design and shifts all 2D actions to the 3D GPU, regardless of whether it is emulated by software or accelerated by hardware. You can test with the attached glxgears script started from a terminal window. Xorg.0_driver_as_rockchip.log: No "Section "OutputClass" so no KMS device identification. No Section "Device" so driver auto probing with modesetting and fbdev. [ 53.702] (II) LoadModule: "modesetting" [ 53.704] (II) LoadModule: "fbdev" modesetting initializes with GPU (Mali) device because of fall back. [ 53.694] falling back to /sys/devices/platform/20000000.gpu/drm/card1 [ 53.707] (WW) Falling back to old probe method for modesetting modesetting outputs to a not display capable device because a rendernode has no scan-out facility. fbdev is associating with framebuffer device [ 54.354] (II) FBDEV(1): hardware: rockchipdrmfb (video memory: 3600kB) I am confused what is going on here and not sure what this proves. Now I see. In the end you get fbdev with swrast. With this stanza you should get the same observation in the performance: Section "OutputClass" Identifier "dwhdmi-rockchip" MatchDriver "rockchip" Option "PrimaryGPU" "TRUE" EndSection Section "Device" Identifier "KMS-1" Driver "fbdev" EndSection "drmdevice" located at libdrm glxgears

That commit was in 2019 and should be available since 5.2. Can you please attach your /var/log/Xorg.0.log?

You will also not see it as built-in, the Rockchip display subsystem will be provided by DesignWare IP. The rockchip driver functionality will be provided by the dw_hdmi module. It will provide a cardX node in /dev/dri/. The 3d Mali GPU IP will use either the lima or panfrost module depending which flavor of Mali your device has. It will provide a renderDXXX node in /dev/dri/. Its companion cardX node is of no use and is only there for drm implementation reasons. The ddx xorg driver (modesetting, armsoc, armada, ...) will use the cardX node for display output. Since Xwindow doesn't know what hardware you have, you can use this stanza to give it a hint instead of let it guess which cardX node to use: Section "OutputClass" Identifier "dwhdmi-rockchip" MatchDriver "rockchip" Option "PrimaryGPU" "TRUE" EndSection This stanza will force instead of autoprobe which ddx driver is to be used: Section "Device" Identifier "KMS-1" Driver "armsoc" EndSection For the ddx driver to support 3d on a different IP it needs the functionality of a submodule (glamoregl for modesetting, etnaviv_drm for armada, but I'm not aware of one for armsoc) to access it via the renderDXXX node. The IPs will exchange buffers via dma_buf with zero copy. The armada driver can configure which submodule to use, so you can combine the i.MX display subsystem with any GPU IP you have a suitable submodule for. drmdevice-rockchip.log

Out of curiosity I built the armsoc driver for my rk3399. I can confirm your observation of the faster display output. Of course, there is no 3D acceleration because the driver has no way to delegate 3D requests to the 3D render node. The armada driver (you want the unstable-devel branch) I use for my imx6 has such an ability and surpasses the rk3399 with modesetting despite the lower specification for now. IMHO armsoc is a dead end until it gets a similar ability. And using glamor with its unnecessary scanout indirection via 3d is also a bad idea. We are all in the same boot, no xorg driver to glue all IPs in an efficient manner together available. xorg-rockchip-modesetting.logxorg-rockchip-armsoc.logxorg-imx-armada.log

The directory gets populated by the UDC driver. I don't know your SOC so I can' t tell in which state the UDC support in the kernel is. When you define a hardware feature in DT, supporting code is not automatically generated in a magical way. Perhaps another forum reader can clarify the status of the UDC support for your SOC.

"/sys/class/udc/" is not a symlink, it is a directory which will hold symlinks to available UDCs. If none is there, the UDC is not set up properly. You have to fix this up first so the USB gadget framework can make use of it.

I've run it three times in a row. This is the visualization of the tmon log, which shows how my thermal system is performing:

With this you make your uboot less flexible and lock out users who want e.g. use dtb overlay features at boot time.

The files can coexist without any harm. As long as distro-boot is active, i.e. an extlinux.conf can be found in the search path, no other configuration files are considered. If you need a feature that distro-boot does not support, you can always switch back to the previous scheme by simply removing extlinux.conf from the search path.

Out of curiosity, I'm interested in how your thermal system works during the test. Can you by chance provide a tmon.log? To collect one, start "tmon -dl", perform your thermal stress test and after round about 15 minutes kill the tmon process. Now post the resulting /var/tmp/tmon.log.

Increase loglevel, e.g. loglevel=9 for everything.

My device is only equipped with this tiny cooling set: Even though all six cores run at 100% load, the fan only runs at full speed for two occasions: Frequency scaling and DVFS haven't even begun yet. The kernel is handling the thermal system, no user space involved. Maybe time to collect tmon's log and investigate how the thermal system is performing.

I find the log that tmon produces quite usable. Just one visualized by throwing it through gnuplot:

You followed the link in the first post about tmon and looked around the directory where the README is located?

The tool is part of the kernel source tree. I don't know how it's packed in your environment but following the README it can be built very easily in the appropriate directory. If not packed for Armbian perhaps a good opportunity to contribute by PR to Armbian.

Use "tmon -dl".

Error prone HW design with floating IO. Proper design with fixed IO states: VCC --------> Pullup Resistor ---| GND --------> Push Button -------+------> PA19 The pullup is already in place. Pressing the button will flip the IO from 1 to 0.

According to your log, which I quoted in my previous post, it was not. Hence my request for the version verify. The wifi kernel driver loads any code that is in the outlined location, and as long as you have not "ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin" and "ln --symbolic /lib/firmware/ap6210/nvram.txt /lib/firmware/brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt" in place, it won't use the desired ones. You can also copy over the code, but I prefer the symlink method if I have to differ from the mainline linux-firmware code. If a mainline linux-firmware update breaks in an incompatible way, I only lose the symlinks and recreating them again restores the functionality. Since these are firmwares for USB host interface attached chips, we are dealing with the UART host interface.

Because "strings ap6210/fw_bcm40181a2.bin | grep 43362" gives me "43362a2-roml/sdio-g-pno-pktfilter-keepalive-wapi-wme-p2p-*unknown* Version: 5.90.195.0 CRC: b99a439d Date: Mon 2014-03-10 15:00:57 CST", I wonder if you have another one or do not use it. The kernel driver is expecting it as /lib/firmware/brcm/brcmfmac43362-sdio.bin for loading. And its companion nvram as brcmfmac43362-sdio.cubietech,cubietruck.txt. If not available it will fall back to brcmfmac43362-sdio.txt. Wifi and bluetooth have to cooperate because they share at least the same antenna in your design. Where user space tools expect and name their resources is a completely different story.

The dtb change was to test if there was some issue with the shutdown gpio. Without that it is relying on the power on reset, i.e. a non working warm boot is expected. It looks like as soon as the BT firmware got loaded, the BT chip stops working. My research has shown that the files in ap6210/ are the ones that were also used with the old user space load method. Therefore, they should be right and work. Maybe it is worth to revert back to the old method and try if this still works. To do this, remove the entire bluetooth {...}; node from the dtb. This way the kernel driver will no longer touch bluetooth and the old method (brcm_patchram_plus, hciattach, ...) should be usable again. What me puzzles is with which hardware we are here really dealing. The referenced cubietruck documentation claims it has an AP6210 with a BCM20710. But the initial firmware announces it as BCM20702A and despite the name ap6210/bcm20710a1.hcd, it contains this string: "BCM20702A1 Generic UART Class 1 @ 26 MHz".

Studying the provided logs gives some clues. After a fresh install I guess there are /lib/firmware/brcm/brcmfmac43362-sdio.bin and /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt in place. With this, the wifi driver get loaded and with no /lib/firmware/brcm/BCM20702A1.hcd no BT firmware upload does take place. The embedded BT firmware in brcmfmac43362-sdio.bin get used and the BT host interface via uart is working. Because the embedded firmware most probably does not match the BT hardware it has to be updated by BCM20702A1.hcd for proper operation. So we are back to find out why this is failing. The only relevant binding in the DT is this line: shutdown-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */ For a test let us remove it from the dtb. Copy the original sun7i-a20-cubietruck.dtb to sun7i-a20-cubietruck.dtb.orig at your workbench. Disassemble the dtb (dtc -I dtb sun7i-a20-cubietruck.dtb.orig > sun7i-a20-cubietruck.dts). Use your preferred text editor to remove the "shutdown-gpios = ..." line at the bluetooth node in the sun7i-a20-cubietruck.dts. Compile the dtb again (dtc -I dts sun7i-a20-cubietruck.dts > sun7i-a20-cubietruck.dts) Now replace sun7i-a20-cubietruck.dtb at the boot location with this one and reboot. This should now be able to upload BCM20702A1.hcd and make BT working to some extent. Since there is no longer any way to reset the BT, this only works after a power cycle, a warm reboot fails. Can you also try the wifi firmware in /lib/firmware/ap6210/ as described above? Because the version has a newer time stamp (date: Mon 2014-03-10 15:00:57 CST) than the firmware you are using. Now that I know the board specific nvram name I just discovered linux-firmware is already carrying a brcmfmac43362-sdio.cubietech,cubietruck.txt. It is identical to the nvram_ap6210.txt except the "macaddr=" parameter. But also the brcmfmac43362-sdio.bin has a newer time stamp (Date: Wed 2018-05-16 23:44:07 CDT). Maybe this one is worth a try also.

Just out of curiosity I took a look at the ap6210 directory on my NanoPC-T4 image: ap6210/bcm20710a1.hcd ap6210/bd_addr.txt ap6210/fw_bcm40181a2_apsta.bin ap6210/fw_bcm40181a2.bin ap6210/fw_bcm40181a2_p2p.bin ap6210/nvram_ap6210.txt ap6210/nvram_apxxxx.txt ap6210/nvram.txt I see they are not only carrying the bluetooth firmware but also wifi firmware and its companion nvram. I don't know where your used ones are origination from but to rule out this special versions are required, let's put them in place. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin and create a symlink (ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin). I don't know if you're using only the generic name (brcmfmac43362-sdio.bin.txt) for nvram. If so, let's do it the proper way. 1. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt 2. Reboot and check dmesg for which <nvram>.txt is being searched. First attempt will try a board specific one, second attempt will try brcmfmac43362-sdio.bin.txt. We are interested in the name of the board specific one. Copy over ap6210/nvram.txt to /lib/firmware/brcm/brcmfmac4356-sdio.<specific name>.txt With board specific name at least one <nvram>.txt for each board can coexist in the searched directory. And yes, in theory, every board needs a specific one. Falling back to the generic can work, but can break as soon as the generic one changes. One doesn't fit them all. Now reboot and check if this has changed anything regarding Bluetooth.

I agree with your analysis, something goes wrong with the hci initialization. What worries me are these lines: Since the driver already works in many other situations, my suspicion is again focused on the board-specific configuration. Just to rule this out, there are no more user space services (with brcm_patchram_plus, hciattach, ...) that might conflict (e.g do some reset) with kernel-mode hci initialization? They are no longer needed with the new mode. Because the user space tools did not rely on the bluetooth DT node (they did there own thing) maybe there is still something not set up properly. Oh, one more idea, can you boot without any overlays. To rule out they make bluetooth non working by pull conflicting configuration. With "strings bcm20710a1.hcd | grep BCM" you can check which version string to expect.

The firmware is probably for your device. If it is wrong for you, it may be missing a feature that you expect. Anyway, the basic functionality should be present so bluetooth starts working. Because the wifi and the bluetooth component share some hardware resources on the module both kernel drivers have to be loaded properly. User space does not need to use the WiFi component, but the WiFi kernel driver must be ready to let Bluetooth work. The Wifi component is attached via sdio and the driver will request the firmware and the nvram like the bluetooth driver. Look at the output of "dmesg" after boot up to see if something is missing.