Jump to content

CNLohr

Members
  • Posts

    26
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I didn't check that the r7p0 driver actually made the node... It's missing. There is no /dev/mali. But, it does say the following: [ 31.338001] mali: loading out-of-tree module taints kernel. [ 31.347176] Mali<2>: [ 31.347186] Inserting Mali v900 device driver. [ 31.347190] Mali<2>: [ 31.347193] Compiled: May 4 2018, time: 02:11:43. [ 31.347195] Mali<2>: [ 31.347197] Driver revision: r7p0-00rel1-d06b414 [ 31.347199] Mali<2>: [ 31.347201] mali_module_init() registering driver [ 31.347382] Mali: [ 31.347385] Mali device driver loaded How would this happen and there be no mali node in /dev/mali?
  2. Do you have any recommendations for SBCs with a better GPU and not a lot of $$? The Mali400 MP2 was sufficient for VR, I figured the 450 MP4 would be overkill. Until Now, I didn't realize Panfrost or Lima even was really a thing. If all I need is to render some triangles, are they suitable for such tests? I can't seem to find any clear instructions on their installation. Vertex shading would be a huge boon, but, I can tolerate it without them. Speed is super critical though. Still want to point out - my current question is how to install the Rockchip Mali Userspace blobs. I can't seem to figure out any configuration that produces a functioning Mali driver.
  3. Anyone know what the distinction between libmali-utgard-450-r7p0-fbdev.so and libmali-utgard-450-r7p0.so It looks like strace says it's looking for "/usr/lib/libGLESv2.so", but, no matter what combination I use it seems to die in the same place.
  4. WOOT WOOT! One more step. Got r7p0 compiled and running by applying mripard to icenowy's sunxi-mali. It found the GPU. Had a few bumps, but really only had to remove __GFP_REPEAT. Hopefully that's not needed... [ 366.671234] cc1: page allocation stalls for 10848ms, order:0, mode:0x14080c0(GFP_KERNEL|__GFP_ZERO), nodemask=(null) [ 366.671263] cc1 cpuset=/ mems_allowed=0 [ 366.671280] CPU: 3 PID: 3545 Comm: cc1 Not tainted 4.14.37-sunxi64 #59 [ 366.671283] Hardware name: OrangePi Zero Plus2 (DT) [ 366.671287] Call trace: [ 366.671306] [<ffff0000080891d8>] dump_backtrace+0x0/0x3f0 [ 366.671313] [<ffff0000080895dc>] show_stack+0x14/0x20 [ 366.671323] [<ffff000008965710>] dump_stack+0x9c/0xbc [ 366.671333] [<ffff000008172d30>] warn_alloc+0x120/0x1b8 [ 366.671341] [<ffff000008173744>] __alloc_pages_nodemask+0x914/0xc10 [ 366.671348] [<ffff0000081c6984>] alloc_pages_current+0x7c/0xe0 [ 366.671358] [<ffff00000819ca04>] __pte_alloc+0x24/0x108 [ 366.671365] [<ffff0000081a1270>] __handle_mm_fault+0xb28/0xc60 [ 366.671370] [<ffff0000081a1470>] handle_mm_fault+0xc8/0x168 [ 366.671377] [<ffff000008097634>] do_page_fault+0x1ac/0x3c0 [ 366.671382] [<ffff000008097884>] do_translation_fault+0x3c/0x48 [ 366.671388] [<ffff000008080b14>] do_mem_abort+0x54/0xd0 [ 366.671393] Exception stack(0xffff00000d7d3ec0 to 0xffff00000d7d4000) [ 366.671400] 3ec0: 000000003a3fe880 0000000000000000 0000000000010811 0000000000001f71 [ 366.671406] 3ee0: 000000003a4007f0 0000000000001f71 0000000000000005 0000000000001f70 [ 366.671412] 3f00: 0000000000000003 000000003a364d70 7fff316f7fff3154 0000000000000000 [ 366.671417] 3f20: 000000007fff316f 0000000000000000 0000000000000001 062b080810100000 [ 366.671424] 3f40: 000000000128ac58 0000ffffac3bab68 0000000001115240 000000003a3fe890 [ 366.671430] 3f60: 0000000000001f60 0000ffffac48d4f8 0000ffffac48b0d0 0000ffffac463390 [ 366.671436] 3f80: 0000ffffac48b9f0 0000ffffac48b9f0 0000ffffac48b9f0 0000ffffac48b998 [ 366.671442] 3fa0: 0000000000001f70 0000ffffca40e810 0000ffffac3babbc 0000ffffca40e810 [ 366.671448] 3fc0: 0000ffffac3b9198 0000000060000000 0000000000000009 00000000ffffffff [ 366.671454] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 366.671460] [<ffff000008082cb8>] el0_da+0x20/0x24 [ 366.671463] Mem-Info: [ 366.671478] active_anon:54381 inactive_anon:54601 isolated_anon:0 active_file:265 inactive_file:345 isolated_file:96 unevictable:0 dirty:0 writeback:0 unstable:0 slab_reclaimable:2084 slab_unreclaimable:4584 mapped:247 shmem:2071 pagetables:1937 bounce:0 free:615 free_pcp:23 free_cma:134 [ 366.671491] Node 0 active_anon:217524kB inactive_anon:218404kB active_file:1060kB inactive_file:1456kB unevictable:0kB isolated(anon):0kB isolated(file):256kB mapped:988kB dirty:0kB writeback:0kB shmem:8284kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 366.671494] Node 0 DMA free:2460kB min:2392kB low:2988kB high:3584kB active_anon:217524kB inactive_anon:218404kB active_file:1148kB inactive_file:1560kB unevictable:0kB writepending:0kB present:524288kB managed:494212kB mlocked:0kB kernel_stack:4560kB pagetables:7748kB bounce:0kB free_pcp:92kB local_pcp:28kB free_cma:536kB [ 366.671509] lowmem_reserve[]: 0 0 0 [ 366.671517] Node 0 DMA: 113*4kB (UMEHC) 36*8kB (EHC) 24*16kB (UEHC) 17*32kB (UEHC) 11*64kB (UEHC) 1*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2500kB [ 366.671562] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 366.671565] 3073 total pagecache pages [ 366.671570] 249 pages in swap cache [ 366.671574] Swap cache stats: add 2613, delete 2364, find 701/899 [ 366.671576] Free swap = 127484kB [ 366.671578] Total swap = 131068kB [ 366.671581] 131072 pages RAM [ 366.671583] 0 pages HighMem/MovableOnly [ 366.671585] 7519 pages reserved [ 366.671587] 32768 pages cma reserved [ 907.725103] mali: loading out-of-tree module taints kernel. [ 907.733352] Mali<2>: [ 907.733362] Inserting Mali v900 device driver. [ 907.733366] Mali<2>: [ 907.733369] Compiled: May 4 2018, time: 02:11:43. [ 907.733371] Mali<2>: [ 907.733373] Driver revision: r7p0-00rel1-d06b414 [ 907.733375] Mali<2>: [ 907.733377] mali_module_init() registering driver [ 907.733531] Mali: [ 907.733533] Mali device driver loaded Now, I'm up to trying this binary blob: https://github.com/rockchip-linux/libmali/blob/rockchip/lib/arm-linux-gnueabihf/libmali-utgard-400-r7p0-fbdev.so Strangely, I am getting a crash when I try starting. #0 0x0000000000000000 in ?? () #1 0x0000ffffbf53a78c in _egl_get_display () from /usr/local/lib/libMali.so #2 0x0000ffffbf53b3b8 in eglGetDisplay () from /usr/local/lib/libMali.so #3 0x0000aaaaaaab1ab4 in CNFGSetup (WindowName=WindowName@entry=0xaaaaaaab5cc8 "Spread Test", w=w@entry=2160, h=h@entry=1200) at rawdraw/CNFGEGLDriver.c:313 I'm not sure how to debug it from here. Any ideas? Do you have any pointers or recommendations? Were could I get eglegears or something like that that I could be careful with?
  5. Ooph. This is rough. I'm currently hoping to use fbdev since that keeps things a loooot simpler on my end because I can re-use the H3 code. I'm not exactly sure where I should go from here. It looks like the rockchip supports r7 and r14, not sure if I should pursue either of the kernel drivers for them? I did make this post... we can always dream: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=3546&extra=
  6. I will do those operations. There's also a new concerning things that has just arisen. The folks over on sunxi-mali have pointed out that the userspace blob for r7 and r8 is unavailable? https://github.com/mripard/sunxi-mali/issues/40#issuecomment-386231407 It may mean that there is absolutely no way of using the GPU on the H5? Is it time to go back to Allwinner and be like "what the heck, guys?" If there is absolutely no way of using the GPU on the H5, why put it there? Charles
  7. I was able to get the r8p0 code running (though I did not follow a guide so I could have messed other stuff up), but still no node found. Is there any way to know if the node is actually present and my problem is with the kernel module or if the problem is still in dtb land? I will try applying the patch a little later.
  8. More notes. I've tried https://github.com/Icenowy/sunxi-mali instead of https://github.com/mripard/sunxi-mali and can't get r7p0's kernel module to patch and compile compile. I've tried stubbing out stuff, but when I got the cma I couldn't figure out how to get it to compile against my nightly kernel. Additionally, I've used `dtc -I fs /sys/firmware/devicetree/base` to see my current dtb configuration and it looks right as long as the h3 and h5 constants I subbed are the same. i2c1 = "/soc/i2c@1c2b000"; hdmi_phy = "/soc/hdmi-phy@1ef0000"; mali = "/soc/gpu@1280000", ""; hdmi_in = "/soc/hdmi@1ee0000/ports/port@0"; ... usb@1c1a400 { compatible = "allwinner,sun8i-h3-ohci", "generic-ohci"; clocks = <0x3 0x21 0x3 0x25 0x3 0x5c>; resets = <0x3 0x12 0x3 0x16>; status = "disabled"; interrupts = <0x0 0x49 0x4>; phandle = <0x2f>; reg = <0x1c1a400 0x100>; }; gpu@1280000 { clocks = <0x3 0x31 0x3 0x72>; resets = <0x3 0x23>; clock-names = "bus", "core"; interrupts = <0x0 0x60 0x4 0x0 0x61 0x4 0x0 0x62 0x4 0x0 0x63 0x4 0x0 0x64 0x4 0x0 0x65 0x4 0x0 0x66 0x4 0x0 0x67 0x4 0x0 0x68 0x4 0x0 0x69 0x4 0x0 0x6a 0x4 0x0 0x6b 0x4>; assigned-clock-rates = <0x16e36000>; assigned-clocks = <0x3 0x72>; phandle = <0x54>; reg = <0x1e80000 0x30000>; linux,phandle = <0x54>; interrupt-names = "gp", "gpmmu", "pmu", "pp", "pp0", "ppmmu0", "pp1", "ppmmu1", "pp2", "ppmmu2", "pp3", "ppmmu3"; }; mmc@1c11000 { cap-mmc-hw-reset; compatible = "allwinner,sun50i-h5-emmc", "allwinner,sun50i-a64-emmc"; clocks = <0x3 0x18 0x3 0x4d>; resets = <0x3 0x9>; clock-names = "ahb", "mmc";
  9. I can't seem to get the system to find the mali node. Perhaps there is something wrong with my patch or patch process. Here is my patch: https://gist.github.com/cnlohr/8164f52c4551d10aaa2c94ad6156c7ae Then, I am adding it with armbian-add-overlay 20-add-mali-node.dts And, reboot. No errors. It find it and says good next time. 20967 bytes read in 567 ms (35.2 KiB/s) 385 bytes read in 507 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo 385 bytes read in 497 ms (0 Bytes/s) Applying kernel provided DT overlay sun50i-h5-usbhost3.dtbo 989 bytes read in 277 ms (2.9 KiB/s) Applying user provided DT overlay 20-add-mali-node.dtbo 4179 bytes read in 477 ms (7.8 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 No hint of mali in /dev or in dmesg. Insmodding sunxi-mali, via the following procedure # apt-get install linux-headers-next-sunxi64 # git clone https://github.com/mripard/sunxi-mali # cd sunxi-mali # export CROSS_COMPILE= # export KDIR=/usr/src/linux-headers-4.14.37-sunxi64/ # export INSTALL_MOD_PATH=/lib/modules/4.14.37-sunxi64 # ./build.sh -r r6p2 -b # ./build.sh -r r6p2 -i # insmod /root/git/sunxi-mali/r6p2/src/devicedrv/mali/mali.ko yields [ 3498.705058] mali: loading out-of-tree module taints kernel. [ 3498.709246] Couldn't find the mali node Any idea where to go from here or how to diagnose why my dts patch isn't being used (despite
  10. Re: not mainlining the module: That makes a fair bit of sense. I was just referring to the dt. I have another question about the dtb. It seems that there is a relatively straightforward process for boot-patching DTs. Is it feasible to create an overlay using this mechanism: https://docs.armbian.com/User-Guide_Allwinner_overlays/ with this patch file? https://github.com/jernejsk/LibreELEC.tv/blob/aw_h5_init/projects/Allwinner/devices/H5/patches/linux/20-add-mali-node.patch if it is, then, it seems that I may be able to get everything working with minimal effort. Charles
  11. Sorry, making one last post so I get notified of replies, I can't figure out how to turn it on for a topic. Just a note if anyone minds updating the documentation: It's unclear where the absolute path is for where the patches should go.
  12. Just because there aren't mali userspace drivers yet doesn't mean the nodes and open source kernel sides shouldn't be mainlined. But I appreciate the information, thank you for adding all three links, since I still don't understand the patching system for armbian. If I can get it working, I will post back here with complete instructions.
  13. I got the mali stuff working on my H3 on my orange pi one to great success for use with the HTC Vive, but I'm trying to get it working on my H5 on my Orange Pi Zero Plus 2. I can't seem to get any work done as far as installing the mali modules/etc since I can't find the mali node in any of the dtb's. Also, because I am trying to use the normal armbian system, instead of installing my own sunxi-next kernel. I've switched to nightly, but can't figure out how to edit my own changes to the dts's that are built to add add the extra mali node (not that I have any idea where the mali450 is on the H5!). Any help would be greatly appreciated. I can't wait to fire this thing up with my HTC vive and see what my new even orager VR experience is like. Charles
  14. OOHHH That makes a lot more sense! Are those tables from that patch still the recommended mechanism for adding new video modes? Once they're added, I suppose I just compile my kernel and they'll pop up in h3disp? I have to admit, I can't recall seeing a table of numbers or anything, but I will try again! The one thing that was a little daunting to me about the patch is that the numbers in the table did not appear to line up to what I was used to seeing in the EDID data or the modeline data I have the vive working with in other arenas, and I didn't see any obvious way to translate. I'm hoping that table /just/ contains the numbers. Charles
  15. Hmm, it still refused to boot anyway. I did not pay attention to if there were other errors on-screen, but, it certainly did not get past uboot. Is that the correct way to apply the binary patch? I admit I was rather confused to hear the developers mentioning using the legacy branch, as I would imagine almost all focus should be on mainline. It feels /sooo/ close. Even though a non-mali option isn't ideal, even just being able to pan the framebuffer would be a workable solution for what I'm working on, and it sounds like that is /very/ close to completion on your guys side.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines