Posts by buzzmarshall

    CvH ... i would if i knew enough about git to safely go about doing so... I barely know my way around git for my own use, let alone someone letting me pollute their sources... It took me 3 commits just to finally settle on how to produce a patch that someone else can use and eventually i will figure out how to delete the early commits on trying to create a patch properly... lol...

    Anyways for now till i learn more about git for anyone looking to build against LE Master branch and running into issues with the mali-bifrost package not building because of the missing mmap_sem structure...

    There is a patch in my LE Master branch under the /packages/linux-drivers/mali-bifrost directory... i created a patch directoy and stuck it in there and it should solve those build issues when pulling the BX301A01B-SW-99002-r16p0-01rel0 package from LE or any other unaltered source.

    Hope that helps for now... its only taken me 3 days now to figure out how to use that part of git... lol...

    sorry i quess i should have pointed to my github for anyone looking...


    *replace the xx with tt to make the link work.

    The AMLG12 is for on master failing at the mali-bitfrost package so i need to isolate the changes as its been awhile since i last built the LE projects when it was working... so some time needs to be spent seeing why it no longer builds for me...

    The Amlgx project i stuck into the 9.2 build i am picking away at correcting a few issues matching that project into the 9.2 build but its coming along bit by bit...

    Stpf99... The answer to your questions is probably more then what should be talked about in this thread as it involves a number of pieces of code in a variety of spots that either needs to actually be created or old code adjusted.

    In short tho it stems from the proprietary vendors bsp packages being done away with as LE migrates to using mainstream packages looking ahead to the future.

    Trying to maintain builds for the growing group of devices is just way to many headaches every time something breaks as each vendor kinda hacked together whatever they needed at the time for that device with no real thought of looking much beyond the initial sales when they introduced the device...

    Amlogic for example, has for years had their own hobbled together player support in the form of libamcodec which Kodi used which has now been removed and replaced with opengles(mesa) which means a number of areas need to be fixed up... The V4L and Ffmpeg projects are probably the most notable ones as they strive to solve the encode/decode issues.

    LE shows the wear and tear while this is going on as while working towards Matrix and the obstacles it brings (like most new versions) they have decided to take a hands on approach with the various mainstream packages and developing the required supporting code...

    CE and most of the other forks are more committed to making use of the vendors proprietary bsp's which has allowed better working Aml images for most of those devices...

    Most of the devices they support are running on are pre-5 kernels usually at 4.9 or 3.14 which because Android on those devices is locked down on kernels in the same general revisions it has allowed for some of the proprietary blobs or firmware to be used in these Jeos Linux Distros to make use of the hardware as it was meant to.

    There is no real easy way with the mainstream road as its a lot of work but there has been a lot of ground gained but more is needed and its just one of those things that has to many unknowns to predict if and when it will all end, so the quest carry's on.

    As for the LE vs CE approach its not a matter of one being right or wrong its simply a choice for the enduser to be aware of the differences and if running on older kernels isn't a concern then CE or any of its spin-offs like AE is probably the better choice for now... As well its probably a good idea to be aware of the differences and issues if looking to buy a new device as there is a lot of marketing out there that can make it confusing when looking at the new devices.

    I will stop there as its kinda outside the intent of this thread but hope that helps point you in the right direction.

    I am assuming your all talking about the normal 9.2 version...

    The master for at least the AMLGX builds ok if you strip out all the bad kernel patches in the Amlogic Project folder.. It appears that a lot of the patches still in the project are for earlier kernels and when building against the 5.8.7 they are already in the source so the patches cause the build failures and by removing them the project will build.

    I have not tested against the AMLG12 projects tho at this time... i just tested the GX as i checked the completed images on some S912/S905 devices which other then the typical matrix issues works.

    I have begun a 9.2 build by moving the Amlogic project back into the 9.2 project and am in the middle of regressing kodi down to the current 18.8 version just to see if it will work...

    I am busy with some other builds so it may take a while depending on what i come across while trying this.

    Anyways i posted this just for the ones that want to play as the more that try the quicker things may happen as i am sure most of the dev's here probaby have their hands full with the limited time they have.

    As for what issues your having with aarch64 builds its hard to say without knowing more...

    Buts as for LE and where it came from... It started as a fork of the OpenELEC project a few years ago and has gone thru a lot of modifications over the years to be where it now is...

    I don't think getting a virtual terminal window on most embedded builds is possible without some serious changes to LE at a core level in how it interacts with the Linux kernel because once Kodi pulls the system up and is the controlling app switching terminals or windows becomes a different thing then the simpler jeos model LE and its spin-offs used.

    I can't speak for all the various platforms that LE builds for but most embedded ones that i have looked at they all seem to be hindered with the same issue.

    Someone correct me if i am wrong tho.

    The usual suggestion if you need a terminal is to ssh into the device.

    That being said i will say from my own experiences in trying to get working/switchable terminals or windows it took some serious rethinking and understanding of how LE works within the JEOS manner to make the alterations and it was something never posted publicly as it it really breaks the ideology of LE which would not be fair to all its developers and their good work.

    someone correct me if i am behind and wrong but to my best i thought kmscube required either the lima or panfrost graphics drivers and opengles v2 support...

    not sure if that is your issue but thought i would add my 2cents and see if someone with more knowledge on the nxp platform will chime in.

    hm... last time i looked the redbull model was a phone not one of their android tv boxes.

    Wechip ouch... talk about bottom of the line... once i bought a couple of cartons of oem boxes from them and i never made that mistake again,,,

    anyways i never heard of a tvbox from them called Redbull unless i am misunderstanding something.

    The only current way that i know of is to build a emulator to emulate the widevine functions which in the case of the 4g sram devices would probably run. The issue tho really comes down to, doing so out in the open community i highly doubt is something Google would take lightly.

    If one is good at RE stuff and proficient in using Ida Pro there is enough info via researching the Patent Offices to create a working emulator. It also helps if your familiar with how Conditional Access systems work.

    I agree with Chewitt says as in time hopefully google will release 64bit version which can be extracted and used as currently is being done. I think widevine will be around for awhile seeing as Googles a major player and companies that big tend to like to keep building on stuff they've already dumped a pile of money into.


    As for the Eny M8S (n200's) for some reason Datrh's seems not to make a actual working img... It works great on all the minix devices but the older Eny's for some reason always ends up with a corrupted file system or can't find the proper partition. The compile goes ok and it produces a img but the image always comes up with the filesystem corrupt message or it can't find the partition its looking so it never expands the system on install. The wierd part is that happens when using a linux box to create the sdcard yet if you use windows and libreelecs sdcreator to create the sdcard it will get past the above mentioned errors and do the install but then it runs really unstable...

    I gave up trying to find the issue with datrh's repo on these old n200 based boxes and made some mods to his build setup and made it work and have been testing it for awhile and it seems fine.

    I just finished updating it to Leia 18.7.2 and once i am done a bit of testing if you want a copy to try, let me know and i will upload it someplace... Its intended for the original Eny M8S using the n200_2g device tree...

    No x92 devices here but i do have a bunch of Sunvell T95 U and K pro's that I use for S912 development and they work ok using the q200 based dtb's and give me all the right peripherals. Currently i am building against a slightly modded LE Master as well as Chewitts Amlogic-master and other then some issues with playback loosing its position when jumping around in the video its watchable and wifi and bluetooth both work. I am sure it will get better in time.

    A few of us decided to commit our time to hevc so the S912 and the S812's now working on mainstream kernel have taken a back seat for the time being.

    As far as what Androids on the boxes i couldn't say as i never boot Android on anything so as a Developer i am kinda off the beaten track as i work under constraints that never care about Android as i always remove it and commit Linux or LE straight to internal storage.

    I still see the S912's a totally viable device if you not really looking for a SBC and want to cheap out so once all this crossover to mainstream and moving up in python stuff gets worked out i think it will still have decent place in the market based on its falling price.

    humantoz... If you have access to a linux box you may want to try and format and partition the WD drive under Linux as i have had issues with some WD's that appear ok in Winblows but acts weird under Linux... LibreELEC is actually Linux and Windows isn't exactly the same at partition or low level.

    I know the WD's will work as i have over a dozen 4terabyte wd drives in my network but usually if i buy a used drive from someone that had it on Windows i have issues with them on my devices... Usually running Linux fdisk at cli or use gparted will partition and format getting rid of the errors.

    If you've got no Linux box just use one of the Live Distro's on a usb stick on your pc to just boot to a live non-installed version of Linux and use gparted or fdisk within that environment to repartition the drive.d

    Sounds like when hooking up the wd on a running system LE is able to find the drive and mount it ok but when booting up theres something in the WD's partitioning that LE don't like resulting in the hangs...

    Not sure if thats the issue but based on trying to use Windows formatted drives in a Linux box thats giving me greif thats were i would start...

    Thanks, what I meant was a source for the 30% speed increase for LE (as in any real comparison been done? or were does the 30% number comes from?)

    I am not sure if anyone has really done much comparing. I know i have been playing around with 64bit userland for a while and even tho it sounds good find there are still issues with some of the support packages and things that kinda make it not worth the effort at this time, but i quess i should also qualify that by it all comes down to what your wanting run as something are still locked into 32bit.

    The only thing that i can think of thats gone the 64bit way would be something like OSMC as i think i have seen others talk about it, personally tho i have never played or even tried OSMC and am repeating what others have said to me.

    I've no S805 devices so i can't speak to them, but currently do have Eny M8S (m8m2-n200) devices now working on a build modeled around LE Master running the 5.6.0-rc4 kernel but still have a few issues to fix and i am sure there are a few others working in the same area as well.

    Currently i have put that part of the project on the backburner while a couple of us are working on trying to fix up HEVC support in the v4l2 and ffmpeg sources as hardware support is a issue with all the Aml devices so it makes more sense for now to put our efforts in those areas. But i do believe support for some of the older devices has turned the corner and not that far away.

    i realize this probably is not the thread to yap about this stuff...

    but briefly i was of the same opinion till some others pointed out to me that because the Mali IP is actually common to all SoC's licensing it that because other SoC's using those IP's are going the stateless way is why i asked... i realize there is a lot of things that need to be changed to implement it but just wasn't sure..

    once again thanx for the input.

    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.

    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