Jump to content

Hugo

Members
  • Posts

    4
  • Joined

  • Last visited

  1. If you get the multicolored waveform it's because you don't have the video codec required to decode the video.
  2. Hoping I'm on the right track here... There is a kernel driver source for mali450 (and others!) on amlogic's FTP here: http://openlinux.amlogic.com:8000/download/ARM/gpu/gpu-2016-08-18-fe6d7b1d1b.tar.gz This is dated 2016. I have downloaded Balbes' kernel source with git, ran menuconfig to produce a .config, and then tried to build the mali driver with this command: sudo KDIR=<kernel_tree_path> USING_UMP=0 BUILD=release make The first issue was that the kernel configuration did not have CONFIG_TRACEPOINTS enabled, and in addition it was hidden in the menu by default. So I edited the kernel's init/Kconfig file after I figured out what was missing: config TRACEPOINTS bool became config TRACEPOINTS bool "Tracepoints" After this, I went back into menuconfig, and the option was set in the General Setup menu, at the very bottom. Saved the .config, tried to compile again. A few trivial corrections later (really trivial, I'm not even a linux programmer and managed to fix them in a few minutes), the next (and current) issue was with compiling the mali_osk_timers.c file. This file is very short, but uses the old style (pre-4.15) timer_list. Again, I managed to correct the majority of it (init_timer becomes timer_setup, easy stuff like that), but there is a single bit I cannot figure out how to port (not being a linux guy myself) in the _mali_osk_timer_setcallback function. It deals with too many pointers for my C novice eyes, but hopefully some of you guys can figure it out? This is supposed to to compile to a mali.ko which doesn't need a user space driver when UMP is disabled in the build process, because it will use the kernel's dma_buf driver (which is already enabled in Balbes' kernel), and X should be able to use the driver as is for DRI. It would be really great if you fine folks could help me port this driver! Thanks, Hugo
  3. Hi guys, I just managed to get the latest Armbian XFCE image working from eMMC all dandy on my Tanix TX5 (s905x 2G/8G), and everything seems to be working just fine, but the only major pet peeve I have is the absence of the mali450 drivers on Xorg.. Without it X is sluggish, and videos extremely choppy. I know there is a driver that worked in the 3.14 series of kernels, is there any way to compile a kernel with mali-drm included in 4.19.6? By digging into the older releases I found one mali.ko file, but it's compiled for 4.19.0-rc7-aml and won't load. Is is possible to have an update to this or am I missing something? Believe it or not I went through the hassle of making myself some images by compiling from Amlogic's openlinux buildroot, but it's extremely capricious, and while it does work after some manual coercing, it runs wayland and I have no idea how to get a desktop going on there. Thanks guys, for giving this old useless android box some new life...
  4. Hi folks, I have one of those cheap boxes based off Amlogic S905X, and while ARMbian boots properly, I really wanted OpenGL support and 2D and 3D acceleration in Xorg. After looking for a while I found Amlogic's buildroot package , which has full wifi, hdmi, and full mali support including GL, and cross compiled an image based off gcc-linaro-6.3.1, uboot-2015-next, and kernel 4.9. I managed to build the whole thing with no major issue, and flashed it using USB Burning Tool. But the box was then stuck in an infinite reset loop. I connected the serial console, and this is the output: The problem is with the Synchronous Abort at the end, but I have never seen that before, and I cannot figure out what is causing it. I know this has nothing to do with Armbian per se, but seeing as it is a u-boot issue, I was wondering if anyone ran into this issue before, and how I can figure it out? While the box was stuck in infinite reset, the USB burning tool couldn't connect at all, and uboot wasn't configured to boot from SD card... I managed to get out of the loop and reprogram via USB by shorting pins 31 and 32 on the eMMC during bootup, and reflashed the stock firmware. Everything is now back to Android and behaving normally, but I really would love to be able to boot that image that took me roughly 6 hours to compile... Thanks for any help!
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines