jcaron

  • Content Count

    24
  • Joined

  • Last visited

Everything posted by jcaron

  1. Last time I tested (back on 5.5), supertuxkart worked for a little while but always ended up crashing after a few minutes. Also some benchmarks went through perfectly fine while others (especially those involving textures) either crashed or resulted in weird display. There were a few patches for the kernel from the panfrost team which I'm not sure were merged into 5.6. It might be good to ask the panfrost team if any need to be added on top of the 5.6 mainline.
  2. IIRC the default build settings for mesa install it in /usr/local when the version from packages goes into /usr. This can leave you in a pretty weird state in my experience. Setting the install path to /usr helps.
  3. You probably need to add permissions to (at least) `/dev/fb0 /dev/dri/card* /dev/dri/render*` if you start X while not root. This works on the Orange Pi 3 (Allwinner H6), it may be slightly different on other hardware.
  4. There’s probably a lot more than just the MBR missing. What kind of file system was it? How much data was in there? How long had you been using it?
  5. Ah indeed, a few dozen pages further it becomes clear...
  6. Can't find anything saying that some GPIOs would not allow interrupts in the doc, but I only looked relatively quickly. It's probably something in the DTB which tells the kernel whether the GPIO has interrupts or not, but I'm not quite familiar with their structure or contents... Another possibility could that the pin is believed by the kernel to be used for another function and thus interrupts are disabled, maybe? If I'm not mistaken GPIO117 is PD21, and PD21 is used by UART2?
  7. According to https://www.kernel.org/doc/Documentation/gpio/sysfs.txt gpio117 either cannot generate an interrupt, or this is not known to the kernel/driver. Trying to find the info in the H6 manual. Are you tied to this specific pin? Note that edge correctly appears for gpio40 for instance.
  8. Just upgraded to the latest Armbian 20.05 with kernel 5.5.0 final. It seems to be working well, however I'm still having issues with Panfrost/T720, just wondering if it's just me (messed up compilation or configuration somewhere) or if others have the same issue. jc@orangepi3:~$ glmark2 --validate ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: Panfrost GL_RENDERER: Mali T720 (Panfrost) GL_VERSION: 2.1 Mesa 20.0.0-devel (git-f09c466732) ================
  9. ___ ____ _ _____ / _ \| _ \(_) |___ / | | | | |_) | | |_ \ | |_| | __/| | ___) | \___/|_| |_| |____/ Welcome to Armbian buster with Linux 5.5.0-sunxi64 Thanks all for the great job! Still having issues with Panfrost/T720 though, I'll post in the Orange Pi 3 thread about that.
  10. The SPI on the header is actually SPI1, so you need: overlays=spi-spidev1 param_spidev_spi_bus=1 That should get you /dev/spidev1.0.
  11. In src/gallium/drivers/panfrost/pan_screen.c, function panfrost_create_screen, blacklist array (line 719 in the version I have). Also note that your chrome://gpu output says "Video Decode: Unavailable". This is (as far as I understand it) completely separate from panfrost/mesa etc. The video decode engine is a separate component in the SoC. There was a long discussion somewhere else in the forum about how to configure/install/compile things for that, though it is probably very SoC-dependent, I have no idea if there's support for the relevant component of the RK3399.
  12. That's weird, because I did the same test yesterday evening, and I have lots of crashes and validation failures. Same 5.5.0-rc6, mesa out of git master. What hardware are you running on? I'm on an Orange Pi 3 (H6, T720MP2). Also, did you remove the blacklisting of chrome/chromium in the panfrost mesa driver? Chrome shouldn't see panfrost. Can you share your X11 config related to panfrost, if any? I may be missing something...
  13. You should probably start by checking what chrome://gpu says to see exactly what is used or not.
  14. Video decoding uses a different part of the chip which is not related to panfrost (and much less to Mesa), does it? Also Chromium is blacklisted by Mesa for 3D (or at least it was a few ago when I checked).
  15. I believe you need to use a 5.5 kernel to get the latest panfrost-related patches (I might be wrong).
  16. Note also that many build scripts will attempt to use several cores to speed things up, but the RAM-to-core ratio of SBCs is often not very favourable to this. You can usually add an option on the command line (often -j) to set the number of parallel jobs to run. 1 or 2 is probably more suitable than defaults like 4 or "number of cores" or "number of cores + 1".
  17. It's actually listed on the page (the Buster minimal variant): The red X means it's not supported, but it's available.
  18. This probably depends on your specific use case and the specific features you use. In my case I find it very stable, but I don't use any of the video acceleration features for instance, or sound, or cameras, and I haven't tested WiFi much. The only thing I'm waiting for is 3D GPU support.
  19. If by BT you mean Bluetooth like I do, it's working in 5.3 on the Orange Pi 3 using the Armbian nightly, it includes the firmware for the chip, there's just a bit of setup to do. IIRC all that is really needed is the init script available in the package included here: and a little change covered here:
  20. Do you mean you can't get any version of Armbian to run on your Orange Pi 3 at all? I have one that's running very well using the Buster minimal version based on 5.3, including X, Chromium, HDMI output, Ethernet, USB, SPI... I have only tested Wi-Fi very quickly, but it worked out of the box. BT and SPI needed a little bit more configuration. I started from Armbian_5.98.191009_Orangepi3_Debian_buster_dev_5.3.5_minimal but have upgraded several times since. Currently on 5.3.7 5.98.191026. I'm booting directly from SD card, if that matters (no eMMC, 1 GB RAM).
  21. I think you already have that one, but just in case, output on an Orange Pi 3 (which should be a pretty recent one): SoC bin: slow chip (bin=1) (raw=1)
  22. Ah indeed, I see that it's actually not whitelisted in the mesa panfrost driver. I also see the mesa panfrost driver blacklists Chromium which is my target use case, so it seems the panfrost+mesa route is not yet viable. So what options are there to be able to use the T720 GPU at the moment, if any? * Only using vendor system images such as those provided * Use armbian + binary driver + X11 driver (e.g. as described here: https://linux-sunxi.org/Xorg + https://linux-sunxi.org/Mali_binary_driver)? Is this actually applicable to the T720 or just the Mali 400 (probabl
  23. I'm not sure I understand the question, but I'm using Panfrost (or at least trying to), which as far as I understand, is the blob-less driver. Not quite sure whether mesa from packages is actually configured with panfrost support, though, is there a way to check that?
  24. Hi, could you provide a few more details about how you got this to work? I just can't get X to use panfrost on my Orange Pi 3, it's stuck on llvmpipe. Kernel: Linux orangepi3 5.3.7-sunxi64 #5.98.191020 SMP Sun Oct 20 02:43:11 CEST 2019 aarch64 GNU/Linux Logs about panfrost: sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff000010becf50) sun4i-drm display-engine: bound 6510000.tcon-top (ops 0xffff000010bf1138) sun4i-drm display-engine: bound 6515000.lcd-controller (ops 0xffff000010be9450) sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff000010bec2f8)