• Content Count

  • Joined

  • Last visited

About drice

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. You have seen this error before. Do you not remember? Look at post #2.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Completely different problem, in fact. Your first post showed a problem with compilation, and now your second post shows a problem running the software you have compiled. Check this file and see what's wrong. I don't know what this software is so I can't give any suggestions.
  13. I ran into the same issue a while ago. This occurs because the binaries in the scripts folder are x86_64 format. As I recall, this can be fixed by the following, but I can't test it now: cd /usr/src/linux-source-4.19.57-sunxi64 make clean make scripts If it doesn't work I can test in a few hours.
  14. I compiled libva-v4l2-request release-2019.03 on H3 with kernel 5.3.0-rc3 (sunxi-cedrus module enabled and loaded) and also added some debug logging to parts of libva-v4l2-request to see where it's failing. Here is what I found: 1. H264 capability is being reported from vainfo on kernel 5.3: 2. Using mpv, it seems like it might be trying to open the same device twice or calling some ioctl that it's not supposed to call twice. Notice how the first ioctl returns 0 but then it looks like it makes the same call again and returns -1: 3. Using vlc, it calls the ioctl twice, but once for an input and once for an output (see the is_output variable, which I added for logging purposes). It seems like it makes it further in the process, but then the errors seen at the end appear continuously until I stop the video (this is the same MPEG2 video as with mpv): The same general pattern occurs when playing H264 with VLC, but the repeating errors are different. I'll add more logging when/if I can, but in the meantime I'm posting this info to see if anyone understands it better than I do.