jock

Members
  • Content Count

    257
  • Joined

  • Last visited

About jock

  • Rank
    Elite member

Recent Profile Visitors

1432 profile views
  1. It could be that your rk3229 board (the 2gb one) is not really a rk3229 but an rk3228a. Try removing from the device tree the operating points above 1.2ghz and try again. Just yesterday I discovered that on the rk3228a both the lima kernel module and the higher operating points are causing erratic issues. Lima was causing the system to hang without any further message during systemd boot. Blacklisting lima, the boot process proceeded further but then I got kernel stack dumps, which were finally solved removing the operating points from the dtb. This is about mainline kernel. Regarding the legacy kernel you can bring the highest frequency to 400 Mhz (instead of 500) in the GPU operating points table changing again the dtb.
  2. It is an attempt to port r7p0 mali kernel driver to work with legacy kernel 4.4. It compiles and the module loads, but then does not actually work well when an application tries to use the GPU. The rockchip legacy kernel already comes with r5p0 mali driver and, despite the version mismatch, I confirm that r7p0 userland blobs works with it. I was able to run quake2 - which is my favorite benchmark - but it was not pretty solid and after a while some GPU errors comes up in dmesg. I didn't found the cause, but it could be that I was just "overclocking" the rk3228a I was using to make the tests.
  3. @hexdump @Alessandro yes I confirm that the rootfs of armbian images starts at sector 8192
  4. Are you using "my" armsoc driver? In this latest kernel I imported the libreelec patches and one of the patches gives the hardware plane which was of the cursor to an overlay layer, so the cursor now has to be rendered in software. You can change this line to HWCURSOR_API_NONE, recompile, and get a software cursor. Normally rockchip SoCs have a special separate hardware plane for the cursor, but I don't know if the necessary bits are implemented in the kernel DRM. I got to take a look into.
  5. @hexdump I just updated the ubuntu bionic images with the legacy 4.4.194 kernel. I'm building a couple of debian buster images with the mainline kernel I will put on as soon as they will be ready edit: mainline images added to the initial post
  6. @MX_Master I sent you a private message with the link to the sdcard image. Anyway I thought that you may double check your libEGL* and LibGLES* symbolic links using ldconfig -p. Otherwise you could create a directory /opt/mali, put in libMali.so and create there all the necessary libEGL and libGLES symbolic links to libMali.so, then run glmark2 (or other gles apps) using LD_LIBRARY_PATH=/opt/mali glmark2-es2 --fullscreen command line, so the app will first check the libraries in /opt/mali, bypassing the - messy IMHO - mesa/glvnd machinery.
  7. Mmmh, no there's definitely something not working... I got totally different results when I tried it myself, but it was with an older kernel and an older X server. It should have worked with latest bits although. I still have the sdcard for the Orange PI PC around here, let me compress and upload it for you.
  8. In theory UMP should not be needed anymore with latest revisions of mali kernel drivers because they use the standard dma_buf kernel api, but you may give a chance.
  9. @hexdump I reply separately about the bootstrap process on newer images: if I understand correctly, you used the boot things from librelec images from @knaerzche. That's true, it boots without erasing the internal eMMC because he used the rockchip tools and the rockchip proprietary loaders to build the image, so the "internal" u-boot detects u-boot un the sdcard and boots from there. If you use the proprietary bootloader chain, the hanging issues you are experiencing may be related to the trust OS (TEE) but it is just an hypothesis with no real evidences. Armbian images instead use the mainline u-boot with the opensource OP-TEE trust OS. This difference in boot software proved to affect the linux system in various ways and mixing the things may result in unpredictable behavior. about rk3228a, it *should* work, but yet I don't provide a specific device tree for rk3228a. It should be trivial to adjust it anyway: just remove the cpu frequencies above 1.2ghz and set the maximum frequency of the gpu to 400 Mhz instead of 500Mhz. There's a lot of confusion about rk3228a, rk3228b and rk3229 socs and seems to be no real reliable way to detect it: @fabiobassa spotted a board with a soc marked as "RK3229", the SOC efuse also says "RK3229" but only boots on RK3228a libreelec images
  10. About the memory issues, that's because I disabled the HIGHMEM option in the kernel because in the early kernel is was crashing the system at boot, so anything above 1G of memory is discarded. I turned on the option very long ago, but I didn't post newer images with the option enabled recently. Just now I'm builing some new unofficial images with latest bits. I will post them in the thread hopefully later About the mali blobs, they are available on the rockchip opensource github account, specifically the "libmali" repository. There's the r7p0 revision for X11 which I tested and it works
  11. I forgot that in newer armbian images the 01-armbian-default.conf forces the modesetting driver, in fact if you look at the Xorg.0.log you posted the loaded driver is modesetting. Sorry, I totally forgot to mention that. Anyway es2_info show the ARM driver has been loaded, but notice that non-fullscreen applications will be slow because there is no page flipping, instead buffers are copied around and that uses a lot of cpu power. If you can, always use fullscreen for your applications. Kodi, for example, should run fine. Also sometimes when you switch resolution it may crash the application. Unfortunately the interaction between mali drivers and X11 is not perfect.
  12. @MX_Master Yes, you need to create a configuration file for X to use armsoc driver. Edit a file /etc/X11/xorg.conf.d/10-armsoc.conf and put this into: Section "Device" Identifier "mali" Driver "armsoc" EndSection also you must be sure that libEGL* and libGLES* libraries are all pointing to libMali.so. Be also sure that the Mali library userspace library has really name libMali.so, because otherwise it won't work!
  13. I don't think you bricked your UT3, you can always recover it shorting the eMMC clock pin to ground forcing it into MASKROM mode which, in turn, tries to boot from sdcard. The procedure is well-documented online and it is pretty straightforward as long as you have minimal practice skills. Also the eMMC There are some reports that the Q8 images above work because someone else already tried it on the UT3. As a matter of fact, most of the things are already there but clearly the device tree needs to be adapted to support all those peripherals which are external to the SoC (like leds, buttons, IR receivers, etc...). The original dts is a very good starting point, but you need to know how device tree works. Also decompiled device trees are a bit confusing at a first glance.
  14. Mainline kernel is working mostly well for headless or simple terminal-based jobs. HDMI and DRM have some issues and probably the device tree is not complete: some video-related IRQs are not caught and the kernel blames for that. I didn't test it very much, but other devices like ethernet, mmc and USB subsystems seems to be already stable enough. Wayland would be great and would avoid dealing with mali blobs, but at the moment just inserting the lima module causes the kernel to issue a stack dump. DRM also is not in a very usable state. I can't give many more details about mainline because at the moment the focus is on the legacy kernel to see what we can get from the SoC and boards; once the situation stabilizes on the legacy 4.4 kernel I'll happily give more love to mainline. Mainline u-boot instead is in good shape for rk3229, I just recently added support for USB booting from the OTG port, but it still requires some fine-tuning to be really usable.
  15. I think you are lucky. The firmware blob is already there (you can see the version: 5.90.125.104), but you need the txt file which is also called the NVRAM. You just need to try to copy /lib/firmware/brcmfmac-ap6330-sdio.txt into /lib/firmware/brcm/brcmfmac4330-sdio.tronsmart,vega-s95-meta.txt and reload the brcmfmac module (or just reboot the machine). If that one does not work or work badly, you may try to copy /lib/firmware/brcmfmac-ap6330-sdio.bin over /lib/firmware/brcmfmac4330-sdio.bin to replace the binary blob too with a blob very specific for ap6330, which may work better and enable 802.11a frequencies too.