TonyMac32

have you tried to unplug/replug the monitor?

Done, and loaded. Now to see what the fallout is. ;-) tony@tinkerboard:~/Desktop$ mpv --hwdec=auto *.mp4 Playing: Avengers_ Infinity War.mp4 [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, timescale not set (+) Video --vid=1 (*) (h264 1280x720 29.970fps) Video --vid=2 [P] (png) (+) Audio --aid=1 (*) (aac 2ch 44100Hz) File tags: Comment: Invader. Annihilator. So-called savior. As Thanos moves ever closer to omnipotence, the fate of the universe rests with the Avengers. Date: 2018 Title: Avengers: Infinity War libGL error: unable to load driver: rockchip_dri.so libGL error: driver pointer missing libGL error: failed to load driver: rockchip libGL error: unable to load driver: rockchip_dri.so libGL error: driver pointer missing libGL error: failed to load driver: rockchip [vo/gpu/opengl] Suspected software renderer or indirect context. Failed to open VDPAU backend libvdpau_rockchip.so: cannot open shared object file: No such file or directory mpi: mpp version: 598cae3 author: Jacob Chen DEBIAN: update rules for release_20171218-2 hal_h264d_api: hal_h264d_init mpp_buffer_group_get_internal used ion In mpp_rt: NOT found ion allocator mpp_rt: found drm allocator mpp_drm: os_allocator_drm_alloc handle_to_fd failed ret -1 mpp_buffer: mpp_buffer_create failed to create buffer with size 4040 mpp_hal: mpp_hal_init hal h264d_rkdec init failed ret -1 mpp_hal: mpp_hal_init could not found coding type 7 mpp_dec: mpp_dec_init could not init hal mpp: error found on mpp initialization mpp: WARNING: setup buffer group before decoder init mpp: command 310002 param 0x2b89ea0 ret -1 [ffmpeg/video] h264_rkmpp: Failed to assign buffer group (code = -1) [ffmpeg/video] h264_rkmpp: Failed to initialize RKMPP decoder. Could not open codec. VO: [gpu] 1280x720 yuv420p AO: [pulse] 44100Hz stereo 2ch float AV: 00:00:56 / 02:29:49 (0%) A-V: 0.000 Dropped: 13 Audio/Video desynchronisation detected! Possible reasons include too slow hardware, temporary CPU spikes, broken drivers, and broken files. Audio position will not match to the video (see A-V status field). @JMCC I'll stop clogging your media scrip thread with development noise, we can put it all here. This is after doing your recommended HWdecode. It isn't v4l2, it is rkmpp, I had some wires crossed.

I'm getting this: [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Failed to get EGL display. [vo/gpu] Failed to setup EGL. [vo/gpu] Failed initializing any suitable GPU context! Error opening/initializing the selected video_out (--vo) device. Video: no video with the mpv-gbm. with mpv (I assume it's still the Armbian default) it plays video smoothly, but is, like above, using 25% or so of the CPU to do it.

@Myy I missed your comment on the initial commit, I need to quite waiting until midnight to do the more interesting stuff. I'm being presented with 5 options under the rockchip_mpp kconfig: I've got MPP_VDEC_DEVICE, vpu decovder V1 and V2, vpu encoder V1 and V2. Are they all needed?

No worries, I'll play Sent from my Pixel using Tapatalk

OK, I have the driver compiled into the dev kernel, enabled, loads on boot: root@tinkerboard:~# lsmod Module Size Used by overlay 90112 1 fuse 98304 3 zstd 16384 4 gpio_keys 20480 0 zram 24576 5 rockchip_vpu 32768 0 rockchip_rga 20480 0 rk_crypto 24576 0 videobuf2_dma_sg 20480 1 rockchip_rga videobuf2_dma_contig 20480 1 rockchip_vpu videobuf2_vmalloc 16384 1 rockchip_vpu v4l2_mem2mem 20480 2 rockchip_vpu,rockchip_rga videobuf2_memops 16384 3 videobuf2_dma_sg,videobuf2_dma_contig,videobuf2_vmalloc snd_soc_hdmi_codec 16384 1 videobuf2_v4l2 24576 3 rockchip_vpu,v4l2_mem2mem,rockchip_rga videobuf2_common 40960 4 rockchip_vpu,v4l2_mem2mem,videobuf2_v4l2,rockchip_rga syscon_reboot_mode 16384 0 dw_wdt 16384 0 reboot_mode 16384 1 syscon_reboot_mode r8723bs 561152 0 rockchip_thermal 24576 0 cpufreq_dt 16384 0 thermal_sys 57344 2 rockchip_thermal,cpufreq_dt sch_fq_codel 20480 6 ip_tables 24576 0 mali_kbase 335872 2 dw_hdmi_i2s_audio 16384 0 realtek 16384 1 @JMCC if I'm not mistaken this isn't going to work with the rockchip software, as it's looking for the vpu_service and hevc_service, correct? being a V4L2 setup probably changes the dynamic a bit...

I went looking for it before I committed, apparently not hard enough. I'll update later.

Pssssst: So, this has @Myy's work with the patchset that got dropped on the mailing list for vdec, I've gotten everything building properly (minus a wireless driver and we don't have 1.7 and 1.8 GHz opps) I ran the media script ans installed everything. I'm watching a 1080p mp4 at fullscreen, here is my armbianmonitor -m: Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 05:41:25: 1608MHz 1.00 20% 3% 16% 0% 0% 0% 51.7°C 0/11 05:41:30: 1608MHz 0.92 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:35: 1608MHz 0.92 21% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:40: 1608MHz 0.93 19% 3% 15% 0% 0% 0% 51.2°C 0/11 05:41:45: 1608MHz 0.93 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:50: 1608MHz 0.94 21% 5% 16% 0% 0% 0% 51.7°C 0/11 http://ix.io/1zbd As for functionality, gstreamer does not seem to want to work, so I would guess the vdec isn't operational yet, or something isn't quite right. In any case, there is hope, perhaps. ;-)

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise. The compromise is reduced with more active participation all around. Now, who is participating? -Vendors: Almost every vendor has some software team, or they pay for one. They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware) -Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc. -Users: buy the board, try our software, ask for/provide help from/to others. Very important for a project, a bit lacking here. Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day. Targeting a group in this requires time of its own, but honestly we need the feet on the ground. It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues. I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board". A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. For other issues that have been a gnawing problem: Decouple the kernel updates from the image type. That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown. I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change. The tag "default, next, dev" would be the build recipe only, ideally. We require the diagnostic output that gives you the kernel anyway. (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ . Etc.

!!! We use Jira at my day job... interesting

Yes, I've had things slip because I looked at a post, then it got buried... It's not the best way. I've been trying to find some project management tools (for my own stuff as well as this)

The 4.4-4.18 images are looking for "miniarm" because we had working images before the mainline device tree was useful. 4.19+ inages the u-boot is looking for tinker dtb, but also has a miniarm DTB to maintain compatibility for the upgrade path. TL/DR: So if you had no miniarm DTB the boot would fail. Ah, also, the old boot scripts (pre 4.19) hate the tinker dtb because of overlays. I turned a bunch of gpio things off so the logic was sane for the overlays.

Did we lose some patches? I haven't come around to Rockchip64.

Well, it still could be. Power sequencing isn't always bulletproof, so sometimes things initialize or don't. To see where development is: http://linux-meson.com/doku.php https://patchwork.kernel.org/project/linux-amlogic/list/ I haven't done any work on 32-bit Amlogic

I'm afraid I have never run a kernel older than 4.14 on this board. I don't know that fex files exist for this board, and that explains the heat and speed issues... I also don't know how to create the appropriate files, again, I haven't messed with old kernels.

Kernel 4.19 has a software spi0 and spidev, but honestly I'm not sure of the rest of the requirements for that board, odds are the I2S isn't going to line up. https://docs.google.com/spreadsheets/d/1dJq7MM1_zA5HtXywDMZ9HMKyPaNgGmkxnuz3wYuk4s8/edit?usp=sharing

Well, I would guess the buttons aren't mapped to functions in anyone's device tree.

And since moved to our Next images. :-)

Compliments @martinayotte: https://github.com/armbian/build/blob/master/patch/kernel/meson64-next/general-meson64-overlays.patch#L133 Add it to the armbianEnv.txt file. :-)

The text all looked fine to me, unless you mean you're still working on the definitions of tasks.

Haha it is the two chipselects as found on RPi. To add another channel you could make an overlay for another set of GPIO, but all of them being software I don't know if that would be very helpful... We could try compiling in the rt-preempt scheduler and see if you can boost the max frequency a bit, the jitter is noticeable even at 500 kHz... (Simple loopback) Can you share what fpga you are using? I've been lazy, and my Ice40 is still sitting on my desk, not used... Sent from my Pixel using Tapatalk

At the moment it compiles in as default on C2 with Meson64-Next and kernel 4.19: https://github.com/armbian/build/blob/master/patch/kernel/meson64-next/board-odroidc2-enable-SPI.patch Sent from my Pixel using Tapatalk

Cool. I have an expanded version of the power hat in mind, and some other small utilitarian sort of hats intended to be low cost for those who want them, of course nothing I can't use will be created unless I get some kind of return, I have only so much time and money to donate... Sent from my Pixel using Tapatalk

Sure, but it can spark a conversation (which it has). I see no foul. In the US a big problem is distance and population density. It simply would cost too much to get fiber to everyone. My test above is a bit strange, since I should be getting 100/20 over a dual-link DSL. ($80/month, should see if there is a better deal, it's been a couple years, now that they deregulated the industry costs are going down) In a lot of places where you have only a few people per square kilometer it is not always possible to get internet unless you go with cellular or satellite, so then the speeds are horrible and so are the costs. Take my mother in law, the nearest "real" population center to her home is 100 km away.

What on earth? Does it say anything else? This sounds like an installed package, not the board support.