MX_Master

Members
  • Content Count

    41
  • Joined

  • Last visited


Reputation Activity

  1. Like
    MX_Master reacted to ning in [Announcement] Xupdate for debian is created. updated mesa for mali GPUs.   
    Xupdate: includes updated mesa libraries for mali GPUs.
     
    how to use:
    add below to you source.list
     
     
    gpg key can be found at:
     
     
    after that, run `sudo apt update && sudo apt upgrade`
     
    before reboot, please update your xorg.conf, follow below webpage:
     
     
     
     
  2. Like
    MX_Master got a reaction from Igor in v20.02.1: `linux-headers-current-sunxi` headers version mismatch   
    Your truth  I forgot to `apt update` first. My bad. Thanks
  3. Like
    MX_Master reacted to jock in Is Mali GPU driver available in Mainline for H3?   
    @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.
  4. Like
    MX_Master reacted to jock in Is Mali GPU driver available in Mainline for H3?   
    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.
     
  5. Like
    MX_Master reacted to hexdump in Is Mali GPU driver available in Mainline for H3?   
    this xorg conf does not refer to the armsoc driver - here is a proven to be working example for an armsoc xorg.conf: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/X11/xorg.conf.d.samples/01-armsoc.conf
  6. Like
    MX_Master reacted to hexdump in Is Mali GPU driver available in Mainline for H3?   
    maybe build your own kernel with lima disabled (i'm not sure, but i think it might conflict with the old mali driver even if the module is not loaded) ... make sure you apply those two patches:
    https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-gem-cma-Export-with-handle-allocator.patch
    https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-sun4i-Add-GEM-allocator.patch
     
    here are my own notes on getting this to work, which are verified to work up until v5.4 kernels:
    https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.av7-mali-sunxi
     
    good luck and best wishes - hexdump
  7. Like
    MX_Master reacted to hexdump in Is Mali GPU driver available in Mainline for H3?   
    another thing to keep in mind is that your user needs access to /dev/mali - usually granted via some udev rule and the video group (usermod -a -G video username) ... example udev rule: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/udev/rules.d/50-mali.rules
     
    good luck and best wishes - hexdump
  8. Like
    MX_Master reacted to jock in Is Mali GPU driver available in Mainline for H3?   
    @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!
  9. Like
    MX_Master reacted to jock in Is Mali GPU driver available in Mainline for H3?   
    The answer is yes, it can be done, but you need a bit of knowledge about compiling kernel modules.
    I made it on an Orange PI PC (Allwinner H3) to test my armsoc drivers and it worked, although Mali-400 MP2 embedded into H3 was quite slow.
     
    You should be able to take everything you need (both the kernel driver and the userland EGL+OpenGL ES drivers) from https://github.com/mripard/sunxi-mali
    Kernel and userland libraries should match their versions to be sure that they work correctly together: if you use r6p2 kernel driver, use r6p2 for userland too.
    Instructions are easy but here are some hints:
    You need the kernel headers package installed, you won't get far without this; you should be able to use apt-get to install the appropriate package for your armbian version You can compile the kernel driver on your very same board (I strongly suggest this), so you don't need to export the CROSS_COMPILE environment variable export the KDIR env variable to point to your kernel headers. Typically: export KDIR=/lib/modules/$(uname -r)/build export INSTALL_MOD_PATH env variable to point to your kernel modules:. Typically: export INSTALL_MOD_PATH=/lib/modules/$(uname -r)/kernel follow the instructions as described, but expect some patch won't work or compile fail. Just don't be scared to get your hands dirty, it is common that you may need to do some little manual adjustments (a missing kernel file here, a missing header there...) Once the driver is compiled and installed, you should be already able to modprobe it.
     
    Follow the instructions to install the userland EGL and OpenGL ES libraries too.
    If you are using the X server, you need the x11_dma_buf flavour and you also need to compile this armsoc driver too (maybe you can try the already compiled version I published on this post, it should work for your SoC too. Ignore the media script part which is for rockchip socs).
    If you don't use X you can use the fbdev flavour, in this case add extraargs=drm_kms_helper.drm_fbdev_overalloc=200 to /boot/armbianEnv.txt as per-instructions.
     
     
     
     
  10. Like
    MX_Master reacted to martinayotte in Switching SUNXI-DEV to 5.6.y   
    I've started the work of switching SUNXI-DEV to 5.6.y, as usual, few DT duplicates and fixes ...
    But I've faced also a big change related to 'file_operations' been changed to 'proc_ops' in all places over the kernel, which cause that all our EXTRAWIFI needs to be fixed.
    I hope to get it done by the end of this evening ...
     
  11. Like
    MX_Master reacted to Igor in Armbian 19.11.y release notes   
    Release details

    https://docs.armbian.com/Release_Changelog/
     
    Upgrading your Armbian to v19.11.y
     
    This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
    apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
     
     
    Choose latest version of 19.11.x and select upgrade according to this scheme:
    Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
     

    Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
    Main build system changes
    Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
    LIB_TAG="v19.08" to your build config file which by default is:
    userpatches/config-default.conf Then run your script as you did before.
     
    Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

    In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

    Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
     
    Enjoy! 
  12. Like
    MX_Master reacted to Igor in Updated images for Rock Pi 4   
    Legacy and mainline kernel.
     
    https://www.armbian.com/rock-pi-4/
  13. Like
    MX_Master reacted to znoxx in missing recordmcount - looks like solved   
    Playing with freshly installed/updated armbian, tried to compile "patched" realtek drivers for those weird realtek 81xx things.
    Bumped error: ./scripts/recordsmcount not found
     
    Go to /usr/src/linux-headers-whatever-version-4.x/scripts
    then, sudo make  recordmcount
     
    After this even DKMS version installed/build without any issues.
    Not sure I will survive next kernel update without manual intervention with this "make", but anyway, it worked for me.
  14. Like
    MX_Master reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y
  15. Like
    MX_Master reacted to saman in Has anybody a good latency after the RT-PREEMPT patch?   
    Hello,
     
    enabled patch for OrangePi Zero H2+ 512 with build environment Armbian 5.41 on Ubuntu 16.04.3 LTS for build Xenial 3.4.113 with rt143.
    Following results:
    dev@orangepizero:~/rt-tests-1.0$ uname -a Linux orangepizero 3.4.113-rt143-sun8i #2 SMP PREEMPT RT Thu Feb 22 17:25:21 EET 2018 armv7l armv7l armv7l GNU/Linux dev@orangepizero:~/rt-tests-1.0$ sudo ./cyclictest -p 80 -t5 -n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.47 0.41 0.70 2/138 20170 T: 0 ( 2844) P:80 I:1000 C:3969645 Min: 8 Act: 62 Avg: 54 Max: 2062 T: 1 ( 2845) P:80 I:1500 C:2646431 Min: 8 Act: 90 Avg: 56 Max: 571^C T: 2 ( 2846) P:80 I:2000 C:1984823 Min: 8 Act: 52 Avg: 55 Max: 346 T: 3 ( 2847) P:80 I:2500 C:1587859 Min: 8 Act: 91 Avg: 55 Max: 341 T: 4 ( 2848) P:80 I:3000 C:1323215 Min: 8 Act: 64 Avg: 55 Max: 297 Following interrupts are reported
    dev@orangepizero:~$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 10: 564 440 442 277 sunxi_gpio_irq_chip xradio_irq 29: 3727320 3647150 3611500 1844956 GIC arch_timer 30: 0 0 0 0 GIC arch_timer 32: 446 0 0 0 GIC uart0 38: 24 0 0 0 GIC twi0 39: 18 0 0 0 GIC twi1 43: 0 0 0 0 GIC PA 49: 1723 0 0 0 GIC PG 50: 0 0 0 0 GIC sunxi_timer0 63: 0 0 0 0 GIC Thermal 72: 0 0 0 0 GIC sunxi-rtc alarm 77: 0 0 0 0 GIC PL 81: 0 0 0 0 GIC arisc_hwmsgbox_irq 82: 0 0 0 0 GIC sunxi_dmac 90: 0 0 0 0 GIC cedar_dev 92: 63924 0 0 0 GIC sunxi-mmc 93: 126255 0 0 0 GIC sunxi-mmc 97: 0 0 0 0 GIC spi0 98: 0 0 0 0 GIC spi1 103: 353 0 0 0 GIC sunxi_usb_udc 104: 0 0 0 0 GIC ehci_hcd:usb1 105: 0 0 0 0 GIC ohci_hcd:usb5 106: 0 0 0 0 GIC ehci_hcd:usb2 107: 0 0 0 0 GIC ohci_hcd:usb6 108: 0 0 0 0 GIC ehci_hcd:usb3 109: 0 0 0 0 GIC ohci_hcd:usb7 110: 0 0 0 0 GIC ehci_hcd:usb4 111: 0 0 0 0 GIC ohci_hcd:usb8 114: 1459073 0 0 0 GIC gmac0 119: 336585 0 0 0 GIC dispaly IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 376490 1088699 535403 326760 Rescheduling interrupts IPI3: 111 112 111 106 Function call interrupts IPI4: 2 1 3 0 Single function call interrupts IPI5: 0 0 0 0 CPU stop interrupts IPI6: 0 0 0 0 CPU backtrace IPI7: 0 0 0 0 completion interrupts Best regards!
    Dani
  16. Like
    MX_Master got a reaction from MitchD in OpenRISC core (AR100) for the real-time tasks   
    Service monitoring and restart functionality can be made by any ARM Linux program or script.
     
    If you want to be shure that Linux OS is running normally, you can use a combination of ARM Linux program and ARISC program. If linux program didn't answering to ping from ARISC program, the ARISC program can restart whole device.
     
    I will use the ARISC firmware just for GPIO toggling. My ARM Linux program periodically will send to ARISC a commands to generate exact number of pulses on the specific GPIO pins, with specific frequency rate. 
  17. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    AFAIK, mainline kernel runs in unsecure mode, where you can't write to secured registers like R_CPUCFG.
  18. Like
    MX_Master reacted to James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    ... and here are the openssl/7z tests: https://pastebin.com/huSB5LhC
     
    @tkaiser updated results with the performance governor: https://pastebin.com/pUR5D7AA
     
    You were right, it makes a big difference to the openssl results at the smaller block sizes.
     
    The board has passive heatsinks only at the moment, fan is still to be added. I saw some temperatures in the high 60s during these runs, so it's possible/likely that some throttling still occurred.
  19. Like
    MX_Master reacted to James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    @tkaiser Memory test you requested on OPi one+ board: https://pastebin.com/ubszDSUH
     
    Temperature peaked at 53C during the test, so should have stayed well clear of any throttling. I added heatsinks this morning
  20. Like
    MX_Master got a reaction from MitchD in OpenRISC core (AR100) for the real-time tasks   
    Thanks again to the jernej.
     
    Finally i got what i want. Now I can upload a firmware and run the ARISC core without any problems with armbian mainline kernel.
     
    Here is a test firmware source - https://github.com/MX-Master/h3-firmware/blob/test_3/main.c (simple leds blinking)
    Here is the uboot script source - https://github.com/MX-Master/h3-firmware/blob/test_3/fixup.cmd
     
    If somebody wants to test it.. the firmware blob and compiled uboot script can be found here
    https://github.com/MX-Master/h3-firmware/raw/test_3/h3-firmware.zip
     
    Tested with Orange Pi One and Armbian mainline image.
  21. Like
    MX_Master reacted to smaeul in OpenRISC core (AR100) for the real-time tasks   
    @MX_Master If you didn't immediately leave IRC after saying something, I wouldn't have to keep logging in to the forum here 
     
    You mentioned using the MSGBOX for communication. I've written drivers for both sides of the MSGBOX (Linux and ARISC) that you can copy/modify from https://github.com/smaeul/linux/tree/msgbox and https://github.com/crust-firmware/crust/blob/master/drivers/msgbox/sunxi-msgbox.c, respectively. If you want to use more code from my firmware, I have a branch at https://github.com/smaeul/crust/tree/feature/more-boards with untested support for H3-based boards.
  22. Like
    MX_Master reacted to James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
     
    The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  23. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    No, you have to either change u-boot code or edit boot script and add memory write command (mw.l), which writes right value to register.
  24. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    Yeah, that's tzpc. I forgot to mention, bsp kernel runs in privileged mode and mainline in unpriviledged mode. That's why you see a difference in behaviour.
  25. Like
    MX_Master reacted to smaeul in OpenRISC core (AR100) for the real-time tasks   
    @MX_Master Try booting with "iomem=relaxed" on your kernel command line. This will allow access to more of the address space from /dev/mem (see https://lwn.net/Articles/302048/).