jock

  • Posts

    883
  • Joined

  • Last visited

Everything posted by jock

  1. @pakos96 Hello! I guess you are saying that is lagging because desktop is not very reactive. For start, it is wisely suggested in armbian to disable the xfce desktop compositor (Menu -> System -> Window Manager Tweaks). Don't expect very fast graphical performance, mali-450 is still a limited GPU. Also, until I don't enable the RAM frequency scaling, the RAM is fixed at 330 MHz (instead of usual 667 or 800 MHz) and this is a huge hit for general graphical performance. @usual user As far as I see, armbian hirsute should have oibaf repository enabled and so Mesa comes as the latest development release
  2. Update! Images with mainline kernel have been updated to Debian Bullseye (minimal) and Ubuntu Hirsute (xfce desktop) with kernel 5.10.68. Kernel is the same major version as previous mainline images, but Bullseye and Hirsute should provide significant newer software packages (including new Mesa libraries for those interested in graphics).
  3. What kind of board you have? We are facing an issue like that right now; for some reason u-boot does not detect the sdcard. BTW, the workaround is to burn the multitool on an USB stick, plug both the USB stick and the sdcard in box and then boot. multitool will happily boot from USB, from there you can burn an image into eMMC, if it is your desire.
  4. Nope, it looks like there is nothing really interesting. Maybe it's just the mesa Lima driver which is just too old. I sorted out the display problems, but then other issues regarding the i2s bus with kernel 5.14 came up. I think I can build a couple of fresh images with the 5.10 kernel which is good enough for now.
  5. All bootloaders allows that, just because the bootloader is not involved in. The kernel driver does the thing: it wasn't there before, hence for performance reason booting at high DRAM frequency was good. Now it the driver is there, so there is no necessity to boot at high DRAM frequency because the driver can do the thing during run-time. You board however has NAND 100%, see clarification on first page.
  6. It says ddr2, but actually works fine with ddr3 too. BTW, I need to update the rk322x_loader to be more compatible. For example, ddr3 frequency is set to 660 Mhz, but it may cause malfunction on some boards: it is unnecessary nowadays because newer armbian releases (even on mainline kernel!) have the dram memory controller driver to allow run-time and on-demand frequency scaling. About the "spectek" bootloader: we noticed that some rare boards only like that old bootloader, using the newer rk322x_loader results in lockups and unstability.
  7. You have to use the multitool stepnand install method for that, otherwise won't work.
  8. Hmm, actually I built an newer image with kernel 5.14 and hirsute and the Lima driver is not playing nice at all. I tried both the stock mesa coming with Hirsute and latest development mesa and both of them cause the login screen to appear just as you describe: black screen and the cursor. Lima driver is somehow complaining with these lines in dmesg: [ 39.136659] [drm:lima_sched_timedout_job [lima]] *ERROR* lima job timeout [ 39.136801] lima ff300000.gpu: fail to save task state from Xorg pid 1654: error task list is full [ 39.136818] lima ff300000.gpu: gp task error int_state=0 status=a so I got to investigate this issue too... edit: uff... ok it seems that the issue is due to the missing operating points in the device tree. I always fall into every time there is a new kernel
  9. I didn't see any overclocked dtb file here around... however I'm not really fond of overclocking for these chips: they already are scrap parts that somehow reach the nominal frequencies. Some of the rk3318 boxes are also downclocked by manufacturers to 1.1 Ghz to be stable, overclocking is not something I would really love about. It's already hard to get the things together and make the board working stable enough. Adding another big source of instability... hmm I don't think it is a wise idea.
  10. @AlwinLub I guess that's a Kivy issue. Actually the opensource driver for mali 400/450 is called lima. It's not up to the performance of the closed source driver, but feature-wise it should be much more standard compliant than the proprietary ARM Mali driver. In fact I can run many opengl/opengles games with Lima that just don't work or work bad with Mali proprietary driver. Performance is not stellar, but they indeed render correctly. The mali_paths python tuple is specifically for the mali proprietary driver, that's why those files are not present in the mainline kernel. You can even manually install the mali driver (and disable the lima driver), but it is something I would not suggest, much better stick to opensource! I'm sorting out some USB3 issue right now for rk3318, once there I would like to update the images with something more recent, like kernel 5.14 and debian bullseye/ubuntu hirsute, so you can also get a much more recent Mesa library with latest fixes and features. In the meantime let's wait for Kivy forum people, I wonder if they already had some experience with Lima driver; in case they are not, it is nice to do some pioneering work
  11. Mainline image contains Lima driver which already has support for opengl. It is good enough to run Kodi, so I don't know how much good will run for your app. 3d games are still quite slow on mali 400/450 and Lima.
  12. @AlwinLub Running weston on legacy kernel could not be a good idea since closed binary blobs probably miss some needed functionality. I suggest you to try the mainline images in the first page or also the mainline image I posted for @Wester_Minskright above The screen tearing can be due to the video being not synchronized to refresh rate: that's normal and hardly we can do anything. If tearing is very heavy with pieces of display moving up and down during redraw, it could be caused by the very same issue @Wester_Minskis having, so I suggest trying also the experimental image I did for him (which has no X11, it has to be installed manually) Soon I will refresh images on first page.
  13. Nope, USB 3.0 is not supported at all in u-boot, and USB 2.0 support is a bit lousy on rk3318/rk3328 too. U-boot non-core code is not the best, it's just "good enough" to let basic things work.
  14. You took your chances and it went good Glad to hear! I wonder which led-conf you choose from rk322x-config (if you choose one). I guess your board gpio configuration is very similar to r329q family (led-conf2)
  15. Nope, not yet, I'm a bit busy with rk3288 at the moment, but here you go: ddrbin_v1.16.bin
  16. jock

    Mainline VPU

    Also on my tests drm-copy is consuming more cpu power. My guess that is because the decoded video buffer is copied for use as EGL image/texture, because the larger the video (and higher framerate) the bigger the cpu usage. Plus mpv uses a single thread for decoding when hardware decoding is in place, so when you saturate a core the video plays slow. I didn't try gstreamer yet, but is it working smooth for you in X11 window?
  17. Cool, thanks for reporting! My box was also stable for hours with your ddrbin, so I think I will promote it as the new default
  18. jock

    Mainline VPU

    I'm in the middle of exploring how LE patches behave with rockchip 32 bit (rk3288 actually) and kernel 5.14. I already did the process some weeks ago for kernel 5.10 and on my rk3288 tv box it worked so far (hantro and rkvdec both were working flawlessy). If you're interested I can point the repository to you when I'm done.
  19. Don't know, but google may help you.
  20. @Wester_Minsk thanks for the logs. I extracted the ddrbin from the backup you posted above and made an image with that. The ddrbin is the thingy that initializes the DDR memory, an initialization with bad timings may be harmful for the system stability, so give a shot to this experimental image (it's a debian bullseye with command line only): https://users.armbian.com/jock/rk3318/Armbian_21.11.0-trunk_Rk3318-box_bullseye_current_5.10.64_minimal.img.xz edit: if you try this on sdcard, be sure to erase the eMMC completely first!
  21. @Wester_Minskthanks for the firmware and photos. I had a quick look into the device tree and it looked quite standard to me: no particular hardware like Power Management ICs or other significant differences from regular tv boxes. I will take a deeper look and check other compatibility things soon!
  22. @Wester_Minsk It could be that your board has some peculiarities we did not ever yet encountered. There could literally dozens of reasons you get a kernel crash, but probably CPU or DDR memories got badly configured. Usually this is a matter of the device tree, but can be related to bootloader too. Could you share the backup you did? It is ok also to share the first 100 megabytes if you don't want to upload the whole package and/or maybe you have some personal contents. From there we can extract the dtb and the bootloader. Remember to compress it before uploading Also a couple or more detailed photos of the board and its main chips (front and back) are very useful.
  23. Yes, the partition is enlarged as soon as you put it in the box. Anyway you can paste the compressed armbian image on the sdcard as the instructions never tells you to decompress it.