Dear all.
I’m using s912 minix u9 with coreelec. I’m interested to testing this version but if I’ve read correctly before use it i have to restore original firmware.
I dont find any post about which features are supported on s912. Please anyone can give me some comments of what is or isn’t working?
Thanks
..well on these build the base system works nicely, but as it is a 9.80 Version Kodi lacks of addons which makes recent builds just usable for playing local files via USB or NAS/Network. Also few addons like youtube, weather and a player for podcasts are available, but most other struggle with python3 support missing (somewhere in dependencies).
If you kept an older build there is much more functionality. My favourites for example are two builds for 905 one from may, one from november which work on my p281-board-boxes with all things I want/need. Both cards are often in use to watch tv, listen to music/radio and such things. On all my aml tv boxes is either armbian or an *reelec installed on internal, but most of them work headless with armbian doing small monitoring jobs or other helpful things.
When you use armbian on internal it is nice & easy to check from time to time the progress in builds writing and booting a card quickly.
Not sure if it makes sense for you to test some of this fresh builds. Maybe do it if you are bored and have much time due corona-restrictions in your area, or if you like to kill some time for other resons.
Once you booted LE from card you should do the recommended backup, that you could go back to android or whatever you got installed easily. If you got CE on internal do maybe a backup to get your setup back quickly before starting to play around at all. If it's on card, you could try to boot written and configured(adjust uEnv.txt to your needs) LE card via toothpick, but most times you will need the fresh android install as starting point into using these LE builds or armbian on s9xxx hardware.
Thanks.
But I was also referring to video support.
Currently with 3.14 kernel, playback is very smooth for 4K HDR videos. It seems that there is a problem with some parameters assigned to the HDR output that seems that newer kernel is fixed.
Do you know if with these new builds there is hardware support from HEVC, AVC?
Currently you'll find depending on the device that a few of the alternative distro's overall that operation is more stable or better because they are still based on the old proprietary kernels and source code which for the time being is still fine for a lot of users. Eventually tho those old proprietary sources will fall by the wayside as Kodi itself is more interested in moving away from that crappy code as it changes to more current api's that are better supported in the mainstream (none-proprietary) kernels looking forward to the future.
Things are changing constantly in those directions as Matrix agenda is also the python3 jump off so there is a shorter list of working plug-ins but that is changing all the time as well...
check the hxxp://linux-meson.com site for a rough idea of the status of which device is supporting what or checkout the irc channels where the dev's are working for info as well.
I have been built Bables AML-ALL and his AMLGX projects as well as LE's master AMLGX projects and find that the images created for S912's seem to be a bit more stable when playing back on the LE Master AMLGX or Bables plain AMLGX then the AML-ALL build. basically the sources in those builds are really close but for some reason i find quirky little things with the AML-ALL build such as when a movie ends it hangs the box at a black screen and you need to reboot it and a few other small anomally's.
Just to qualify things i am as well only testing with playback of locally stored media from my network boxes and am basically running at 1080p with stereo out into a 4k tv, and i am not really using much in the way of plugins other then youtube and this cbc pluging i am trying to fix up.
AMLGX nightlies will resume when someone pushes a fix for wireguard in master. I should probably start a separate thread so that users don't get confused with the different setup in Oleg's images.
I think the problem has been solved!
I was missing it.
The construction is ok.
But it won't boot without a boot! KI pro
If you have a u-boot in SPI\eMMC, use the image for odroid-c2\nanopi-k2 with the correct DTB. All images (except g12) share a common core and differ only in a set of startup scripts.
I've tried both the C2 and K2 images (with the correct DTB) with my LaFrite, but neither will boot successfully. Any other advice?
PANiCnz If using the official nightlies you can either use the "box" image with the correct dtb named in uEnv.ini written to USB - this uses the internal SPI u-boot which will find our boot files, or you can use the "lafrite" image which uses extlinux boot config and our own u-boot. The C2/K2 extlinux images will not boot on LaFrite; the C2/K2 are GXBB devices and LaFrite is GXL, so the device-specific u-boot 'fip' sources are not compatible. Note that the 512MB LaFrite board will boot but Kodi will not start due to the current CMA allocation in device-tree/kernel. If you search the forums there's a thread where another 512MB board user figured out some tweaked settings that allow Kodi to run - and he is sharing his images.
erbas If you want to boot a Ki-Pro you need to use the 'box' image. The C2 u-boot BL1 firmware checks for C2 hardware and aborts if not found. We do not (and have no plan to) support emmc install on GXBB hardware.
chewitt My apologies it's all working error on my part!
The dtb had been renamed wrong.
The boot is perfect, fast.
PANiCnz If using the official nightlies you can either use the "box" image with the correct dtb named in uEnv.ini written to USB - this uses the internal SPI u-boot which will find our boot files, or you can use the "lafrite" image which uses extlinux boot config and our own u-boot. The C2/K2 extlinux images will not boot on LaFrite; the C2/K2 are GXBB devices and LaFrite is GXL, so the device-specific u-boot 'fip' sources are not compatible. Note that the 512MB LaFrite board will boot but Kodi will not start due to the current CMA allocation in device-tree/kernel. If you search the forums there's a thread where another 512MB board user figured out some tweaked settings that allow Kodi to run - and he is sharing his images.
Thanks chewitt! I am successfully running the official nightlies. What's the difference between the nightlies and balbes150's build? Should I expect smooth video playback with the nightlies? or is the code still too new?
Oleg is on an mission to ship a single "ARM" image that (multi)boots on Allwinner, Amlogic and Rockchip hardware. From a userspace perspective this not hard now that all three SoC plaforms are using lima/panfrost, but it requires some differences in the u-boot scripts and boot configuration. Other than this (once booted) his images should be much the same as official nightlies - he is normally using my Amlogic kernel patch-set as-is (he feeds me any changes he finds to send upstream so things are mostly in-sync) and Kodi things are based on LE master.
Playback should be smooth except for HEVC (software decode is beyond an S805X board, hardware decode for HEVC is still work in progress). If you attempt to seek you will see hangs and it's likely the end of playback might require a reboot. It is proving to be an epic quest to get someone interested in the changes the V4L2 stateful code path in ffmpeg needs to solve those things. Raspberry Pi is about to hit the same roadblock though, so that's probably the road to success for that quest.
I have an R-TV S10 (aml912 3GB 2GB/32GB) box and nothing works on it except for balbes150 images, so thanks for that!
However I'd like to use it as a LibreELEC dedicated machine and while the newer images work (sorta), I'd like to have an older build installed, since the test versions aren't really usable (missing HW decode and too new for my old skin/addons).
balbes150 , is there some place where one can download your older builds, those where the HW acceleration wasn't broken?
Alternatively, is it possible to build from source an Image that works with your boot system? I've tried to look into it, but the guides are outdated and the required files aren't there anymore.
Zameero If you disable hardware decode in Kodi player settings you can probably watch all 1080p media without issues - the S912 has lots of CPU on hand and ffmpeg behaves when software decoding. For the sake of asking - which device tree file are you using?
Software decoding is enough for 1080p media, but not for anything higher.
The dtb from the Khadas Vim 2 works fine.
Chewitt If you don't mind can you expand on the "changes the V4L2 stateful code path in ffmpeg needs to solve those things" statement a bit?
Are we talking about just straightening out some bitstream path issues within the current v4l2 and ffmpeg sources or are we talking about creating a better HEVC Userland API that would expose via the V4L2 Stateful codec Api?
Ive been researching the current v4l2 API as well as looking at some of Hans Hans Verkuil and some of the other Collabora work as well as some of what raspberry's coders have done up till now. Sorry if the terminology is off as i am trying to get a better understanding of how the pieces fit together as well as where the issues and bridges to still be crossed are.
If the question warrants being asked someplace else please let me know and i will ask there
thanx. buzz
The original Amlogic vdec work last year was done before a firm API was agreed and documented for stateful decoders, and the current stateful V4L2 code path in ffmpeg is based on that work. Since then the API was confirmed, and most of the vdec code has been reworked for it (HEVC is the main remaining one - it's also the most complex so has been deliberately left until last). Now ffmpeg needs to have the matching userspace work to align a few things around the confirmed specs. There are a bunch of things that need tweaking, but main thing that doesn't work right now is flushing/draining so we see hangs with seeking and when you reach the end of file (end of playback). Raspberry Pi needs the same/similar changes; RPi0-4 use the same stateful path for H264 and some other decoders in the original RPi IP, while H265 which is new IP added for RPi4 is stateless and uses the same code path Allwinner/Rockchip use (which is already in good shape). There are a couple of people who can do the work, but it's taking an eternity for other items to be cleared from their to-do list (mostly HDR related) so that fixing this is the top item.
I should probably start a separate thread so that users don't get confused with the different setup in Oleg's images.
Yes, it would be a good solution. Now there are many differences in the composition of official images and my builds. This requires different handling rules, which may confuse users.
Will test with other files and formats later too, but mp4(as the testvideo) played always perfect in history and behaviour with that file on armbian is normal..
These are completely different systems, with different principles of working with media content, they do not need to be compared.
I've tried both the C2 and K2 images (with the correct DTB) with my LaFrite, but neither will boot successfully. Any other advice?
What media did you try launching from ? What is in SPI and eMMC (does it have its own u-boot)?
The C2/K2 extlinux images will not boot on LaFrite; the C2/K2 are GXBB devices and LaFrite is GXL, so the device-specific u-boot 'fip' sources are not compatible.
You are confusing users, what you write applies only to the official versions. My versions use a single startup system and if configured correctly, you can run any image from RK AW AML.
We do not (and have no plan to) support emmc install on GXBB hardware.
This information is the same only for the official versions, in my images installation in eMMC works for all platforms. 
is there some place where one can download your older builds, those where the HW acceleration wasn't broken?
No
Alternatively, is it possible to build from source an Image that works with your boot system? I've tried to look into it, but the guides are outdated and the required files aren't there anymore.
If you are a LE developer, email me at Slake in PM, I will explain in detail how to do this.
Chewitt... thanx for that bit of info as it clears up a few things i wasn't sure about.
As well i have been looking at Maxime Riparts work over on Bootlin and the stateless stuff they have apparently somewhat working on some of the Allwinner SoC's and Rockchip as well. So that kinda had me wondering what direction was better to look into "stateful or the newer stateless" and didn't want to go in a direction that was opposite to where everyone here is working towards.
Dafna Hirschfeld's virtual driver setup is kinda interesting as well... anyways i digress.
thanx, once again.
