drice

It appears to be decompression of initramfs taking 31 seconds: [ 6.147142] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 6.148094] PCI: CLS 0 bytes, default 64 [ 6.158734] Trying to unpack rootfs image as initramfs... [ 35.413752] Freeing initrd memory: 7632K [ 35.462578] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available [ 35.482492] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available I suspect this is due to the CPU starting at a very slow clock speed. The speed of these algorithms should be much faster: [ 4.104906] raid6: neonx8 gen() 26 MB/s [ 4.172463] raid6: neonx8 xor() 21 MB/s [ 4.242370] raid6: neonx4 gen() 27 MB/s [ 4.309700] raid6: neonx4 xor() 21 MB/s [ 4.379941] raid6: neonx2 gen() 20 MB/s [ 4.446522] raid6: neonx2 xor() 19 MB/s [ 4.517607] raid6: neonx1 gen() 12 MB/s [ 4.583751] raid6: neonx1 xor() 14 MB/s [ 4.653424] raid6: int64x8 gen() 14 MB/s [ 4.721122] raid6: int64x8 xor() 9 MB/s [ 4.790970] raid6: int64x4 gen() 15 MB/s [ 4.860366] raid6: int64x4 xor() 10 MB/s [ 4.934680] raid6: int64x2 gen() 10 MB/s [ 5.003469] raid6: int64x2 xor() 8 MB/s [ 5.079205] raid6: int64x1 gen() 6 MB/s [ 5.151255] raid6: int64x1 xor() 6 MB/s [ 5.151948] raid6: using algorithm neonx4 gen() 27 MB/s I don't know how to check or control the initial speed of the CPU when the system is booting.

It seems like manufacturers should want to sell as many chips as possible, and it seems like they could sell more chips if they released the documentation to allow anyone to implement their product. But many devices or peripherals (i.e., ARM Mali, Allwinner CedarX, etc.) are undocumented and need to be reverse engineered. I noticed this when when I was looking at the RK3399 data sheet and saw all of the features this chip has. It's a shame that of all those features, the only ones that will be used on most SBCs are the ARM cores and the simple I/O peripherals (SPI, I2C, GPIO). I don't have the skills yet to write an OS driver, but I know how to write bare-metal embedded drivers using the information in a data sheet, and I wonder why the manufacturers don't release that information for many of their SoC products. What does a company like Allwinner or Rockchip gain by making it more difficult to implement their products?

PuTTY supports 1500000 bps but the PL2303 does not. The data sheet for the PL2303 shows that it works up to 3 Mbps but it only supports certain discrete baud rates. You need to use a USB serial adapter with an FT232R chip to support 1500000 bps. I've heard that CH340 also works but I have only tested and confirmed with FT232R.

Thanks, I'll get one of those.

NanoPi M4 uses 64-bit (aarch64). Raspberry Pi uses 32-bit (armhf). You need to obtain and compile a version of Qemu for aarch64. I cannot provide instructions for that.

Can anyone provide a link to a currently available and confirmed working USB to 3.3V TTL converter that works at 1500000 bps? The PL2303 I have technically supports up to 3 Mbps but only in certain discrete steps, and 1500000 is not one of those steps. The MCP2221A only supports up to 460800 bps. The FTDI FT232 data sheet claims support up to 3 Mbps but is unclear about whether arbitrary baud rates are supported, or only discrete steps like the PL2303. Searching for a compatible USB-TTL cable to work with the RK3399 has been futile so far. A link to a confirmed working cable would be much appreciated. Confirmed working cables only. No theoretical devices, please.

I think many people don't know the difference between video acceleration and graphics acceleration until they start researching this topic. When I read questions about any type of acceleration for single-board computers I always assume the question is about hardware video decoding unless it specifically mentions 3D or gaming.

I thought the same thing until I actually tried to do it. It's much more complicated than I thought, but at least I learned a lot by reading kernel code and documentation so it wasn't a total loss. Hopefully this feature can be introduced eventually as it will be very nice when it works.

Did you rebuild the scripts as shown in post #2? Are you sure it's the same error? Scripts must always be rebuilt when compiling natively because the kernel package is built on x86_64 so the binaries in that directory will be x86_64 format and must be rebuilt for execution on ARM.

The problem in the previous post (unable to load driver: swrast_dri.so) was because compiling and installing the lima userspace driver somehow changed the DRI library search path from /usr/lib to /usr/local/lib. But after resolving that, I still was unable to figure out how to make Xorg use lima_dri.so instead of swrast_dri.so. I'm setting this project aside until I find new information.

You have seen this error before. Do you not remember? Look at post #2.

I finally managed to compile the Lima driver on the Orange Pi Lite by shutting down X and setting Ninja to use only 2 jobs at a time. Earlier problems were caused by out-of-memory conditions while compiling certain C++ files in Mesa. Unfortunately, all it seems to have done is broken the software OpenGL rendering that used to work: drice@orangepilite:~$ glxinfo name of display: :0.0 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast X Error of failed request: GLXBadContext Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 50 Current serial number in output stream: 49 More research is obviously required.

I'm starting to think that the "Device or resource busy" error might be due to the fact that Xorg is using fbdev instead of the lima DRM driver. I'm going to try to get the lima DRM driver compiled but that seems like it will be a project in itself. My first attempt failed due to an internal compiler error, but I think that was caused by the CPU overheating.

I don't know how you ended up with this version of the kernel source installed on the 32-bit Orange Pi Zero, but you should start over with everything and make sure that you use usb-redirector-linux-armeb-gnueabihf with 32-bit kernel source (i.e., KERNELDIR=/usr/src/linux-source-4.19.57-sunxi). Do not use arm64 usb-redirector and do not use sunxi64 kernel source. Do not randomly try different things. The combination I listed is the only combination that will work. If you don't have those items installed, you need to get the installed. You can't substitute other similar items for those.

Why are you compiling the arm64 version on Orange Pi Zero? Why did you use 64-bit kernel headers to compile the 32-bit version? I didn't notice at first you were using the wrong kernel headers. Orange Pi Zero is H2+ which is 32 bit.