The VDEC is a problem on all Amlogic hardware. There is partial support for H264 and VP9 upstream but HEVC is missing (we have patches, but rather rough on newer hardware) and the kernel driver really needs to be reworked and split to better handle the memory needs of older vs. newer Amlogic hardware generations. The developer who was originally working on it had to stop for personal reasons in late 2019, then Google changed funding priorities and work that was already stalled, stopped. Since then nothing happened beyond dusting off some WIP code for HEVC. The upstream H264 and VP9 drivers are technically meeting kernel V4L2 compliance, but more work is needed in ffmpeg (and the drivers) to get the userspace side working well. The Raspberry Pi foundation devs have done some of the work to get H264 working well with ffmpeg v4l2m2m in their codebase, but beyond a point the improvements need to be matched with driver tweaks and Amlogic has nobody to make the tweaks.
This is THE challenge. Most of the Amlogic community developers are either lacking the architectural talent to write modern drivers from scratch and/or are simply content to fiddle around the edges of the vendor kernel which is ugly-arse code but more feature complete. So there isn’t really anyone to do the work, and this is the status-quo for two years now. Unless someone competent just appears out of nowhere willing to make a large personal and pro-bono effort, the most likely route forwards will be organising a group of commercial backers with an interest in upstream Amlogic SoC support to pool funding and pay Baylibre to do the work. To write, test, refine, and upstream drivers and userspace code has been estimated at 5-8 months work for a professional developer, which means it’s a non-trivial sum to raise. Based on the similar effort I’ve first-hand witnessed the Pi Foundation devs make for RPi4 support it’s probably a low-side estimate.
To a lesser extent the audio drivers also need attention to add support for IEC958 pass-through, but that’s partly due to a dependecy on dw-hdmi and the Allwinner/Rockchip community devs will probably tackle that with time.
Hi all,
I ordered (or preordered, whichever) the D4E16H model from ALLNET China roughly three weeks ago and got it (in Ohio USA) the other day. And I’m nobody at all.
edit: apparently their store allowed me to select no header and onboard antenna even though there’s no such combination listed on the linked page with SKUs, which may be why I still got the header. It seems to be the store’s problem, and according to the page’s feature selection function, it looks like I underpaid by $0.80.
There are 4 basic variations (or models or whatever) with 4GB RAM. $45, $55, $65, and $85 are for the available eMMC sizes-- 16GB, 32GB, 64GB, 128GB, respectively.
GPIO not at all, has no need to be. You never will get exact as SoC pin muxes are never the same.
If you want audio get a usb sound card the whole raspberry hat thing for audio is just stupid when a $3 usb card can do the same.
The only thing that is missing is likely a CSI/DSI but hey, but audio is no problem.
I am not sure why other manufactures continue with the low density 40pin gpio as its had its day anyway but relatively pointless to emulate when its not pin compat exact.
Prob should be an daughter board so you can route the pin mux from a higher density connector.
@eragefe , I was thinking about that , when looking at TDMB . My original comment was:
‘Also this interface to me seems oddly drawn in the cct diagram , so I am not 100% sure that pins 31 and 33 are fully connected at the 8601 GPIO end . This would need examination of the hardware ‘.
As it turned out looks like those pins might not be connected after all . To me TDMB looks more suited to inputting i2s data , so I did not pay it much attention , since my main interest is Volumio .
For i2s output , to a DAC , in the case of streamer applications , to me TDMA looks like a better option .
And from the look of the cct, pins: 12,13,16 and 18 are connected to the header , also they go via a voltage isolating chip , I guess to make it more compatible with any different type of DAC and protect the soc. And if I was to make a guess how to connect a DAC over i2s to Rzero , I would try pins 12,13 and16 , for Data, bclk and lrck respectively.
Thanks for the answer. I was interested to use it in slave mode with external clocks. But anyway. I just dont understand why not connect it when several pins are not connected.
