Posts by buzzmarshall

If your using the actual pine ir-remote you should be able to just follow the thread here on LE regarding setting up ir-remotes... I think you can find that thread under the Wiki tab.

Pines remote is using the nec format and should be as simple as putting the pine64.toml into the rc_maps.cfg/rc_keyboard as per the IR Remote thread under Wiki. Im not sure about the box your playing with as i am using just the normal rockpro64 sbc which that remote is also meant to work on... in my case the sbc has a vacant 3pin header the pretty much any ir-receiver 3 pin package can be put into and then you will need to map out the remote your using where as the actual Pine64.toml is already built into the sources so you just need to set it using the proper toml file. hope that helps

sorry,,, brain fart as i didn't actually look at the link chewitt posted as thats the wiki link you want to follow...

Ive been doing this since before sites like this even existed as i was one of the original hackers to put linux on the original so-called android boxes and everything Chewitt says hits the nail right on the head. Even after all these years this part of the equation has not changed as the factories pump out crap without much concern for software as they pay for basic canned versions of Android to make their hardware work and then leave the product to move on something newer that's easy to sell with inflated talked about what the new hardware can in theory run. Anyone that has been at this for awhile quickly learn that specs in theory and whats really available are very seldom the same in practice...

!st it was the Android box market, now its the Small Embedded board market but the tactics are the same. People should just listen to others like Chewitt here and pay attention to what they have working and purchase based on that and NOT some BS dealer trying to sell their crap based on new device specs.

just my 2 cents as i long retired and moved to other things to play with.

On another note... couple of years ago i bought a HK1 Rbox R2 which is a RK 3366 device and tho sticking linux on it is not all that hard its still the same old story with the gpu issues and hardware decoding even when doing all my own developing and for a hobby its just easier to go buy something that you know is better suited and further down the development chain that others on sites like this use and move on.

The real long and short of all these issues are in the fact the GPU development is a protected environment where IP values are so great that getting any real software/firmware that truly works with the codecs is a game for the rich as no corporate company like ARM is going to stray from its revenue stream is make the info available as a good part of their business model is based in IP and licencing which none of the manufacturers will pay for and in the long run has proven to NOT effect their sales, so they leave to places like this to bail them out with the public and crap they sell them.

hm... its been a few minutes since playing with boxes and I realize the post is a bit old but for the sake of others looking... I have built and currently run a Rockpro64 with LibreELEC 11.04 and wifi using Pines wifi sub-module works fine for me as well as BT...

I stopped by because I am working on a HK1 Rbox R2 (rk3566) and noticed this post and thought i would respond regarding Pines Wifi adapter for the Rockpro64 as it's worked on any of the boards ive used it on.

Your right tho as for dev on the rockpro64 not being the greatest... Armbian works ok but unless your willing to use Docker on your build machines it is way to much grief trying to get it to build properly. Personally i don't use docker or containers for any sort of development tho i am sure there are others who prefer them. anyways take care.

Quote from Master One

So how did he manage to get LE Matrix to work on a S905X3 device? I could not find any info or image for that.

Sorry i should have clarified that...

We are building our own stuff while working on some fixes in LE' s Master as we go... so there is no firmware files of our stuff posted here...

but as CvH said... the Amlogic projects in the LE' s master branch work if one wants to play and build them its just some packages need to be patched and fixed to get the seek to properly work as well as a few other things...

my interests are mostly focused on the older meson8m2 and gxm devices as i have a whack of S812s and S912s that i want to keep working, its not that i don't have most of the newer devices, its just less time consuming for me to fix my old stuff as i have other projects with higher priority and i have lost most of my interest in the media side of embedded devices so pretty much only dabble when asked to help by my buds.

It will be interesting to see just how far Arm's support actually goes... yes they are being more forth coming in information and documentation on some things but thats not the same as actually releasing code... the released info will definately help as it helps eliminate a lot of the RE quess work but how much further they go is yet to be seen, as well with Nvidia buying Arm i am sure they will have something to say as well...

still tho its a good sign...

The shields are nice units its just from a cost point they are rather expensive as your getting into the territory of for a bit more you get more... I've had a few of them over the years since they were 1st introduced and adding all the extras tend to add up making them a bit on the pricey side... other then that tho i think there a decent device...

Being as i still haven't spent any money on a s905x3 device i have not tried LE's master on them but do have a bud that has played around with LE Master and has Matrix working on them... outside of the typical Matrix issues he seems to like messing around with it.. he had a issue with wifi on his brand as it has a MT7668 on his device which i got going for him... other then that he likes that it was cheap and seems to work ok...

From my perspective pretty much all of the Arm based embedded devices when trying to run linux on them are all basically in the same boat when it comes to real gpu support, thou Allwinner and the Rpi4's maybe slightly ahead in some ways... Until some good open source drivers fill in the blanks which is the real unknown.

Personally being pretty much self sufficient i have just stuck to building on the older S912 or S812 devices based on Leia as i basically am not that picky about a lot of things other then just being able to keep the family happy watching stuff off my local storage arrays.

So far i have not played with any of the All winner devices so i can't say to much... I did look at the H2's being they are Intel based which gets one out from under the Arm gpu issues, but found them kinda of expensive when compared to some of the other better sbc or small computers as well as i had issues with both H2's i bought as they seemed to be poorly flowed at a board level which kinda surprised my for HK.

Your right tho its not a easy decision to make as there are so many variables between the available choices...

The other interesting thing is now that Nvidia has bought Arm it makes one wonder what twists we can look forward to as for help on the open source drivers most of these Arm based Gpu's on most of the Amlogic and Rockchip devices...

With these embedded devices its pretty hard to speculate on the future as for which is the best as there are basically 2 forks in the road going on.

Projects like Kodi and LE are focused on following the future by moving into the mainstream kernel which represents a better method of supporting different hardware which goes outside just the perview of linux on embedded devices like the typical Android boxes, and in doing so has been removing pieces of code that were based on the vendors bsp's which tend to be done in a out of tree manner specific to themselves... In this case Amlogic is the mostly mentioned in this thread. Doing so has meant some pieces of the overall setup need to be either fixed or outright created and its mostly being done by various open source groups which takes time. hence some things at this time still need to be fixed.

The alternative approach taken by projects like CE or AE or any of a number of other forks is to try and maintain the devices by using parts of the older vendor packages which has 2 basic effects to it... one is that basically a number of devices still currently work ok with the current Leia version while two being stuck on some older packages such as the kernel and some of its support packages. Currently running on older stuff like this seems like the better way as overall it pretty much works, but once Matrix is finally released who knows where it will leave any of these distro's that took this direction.

There is just no way to know when or even if any of the issues will be fixed as overall things appear to be going in the right direction but its been a long road and the end still hasn't been reached yet.

Its probably best to look to buy based on what your current needs require rather then try and make a purchase based on how long and good some device may be like you typically would when make a normal computer or laptop.

The only way to avoid this whole mess is to basically just give up on trying to run a JEOS system like LE or CE and stick to running the Android version that came on the device as then whatever the devices abilities are can simple been seen by reading the spec sheet of the device to see if it supports the features you want.

People need to remember... Companies like Amlogic Rockchip and others never intended for anything Other then Android to run on Their device which is what the device makers paid for in support and IP licenses. Its NOT until people try and run Linux that most of these issues really have any relevance... but if you really want Linux then its either pick a distro like CE which works but is vested in older vendor packages (which will eventually break) or pick LE and make sure to buy a device that is currently supported by LE for the time being.

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...

hxxps://http://github.com/buzzmarshall/LibreELEC.tv

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

I have finally managed to fix the issues with getting the AMLG12 to complete the build...

i need to dig out a device to test things and see if it actually runs tho... and then i will push the build and patched up to my github...

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.

wowwow...

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.