Posts by buzzmarshall

    Assuming you've tried the typical things like cables and connections i would start with trying any old external video card in the system to see if the issue is actually the embedded hdmi interface or not... any old card would do as long as its got the hdmi out as the exercise is to see if the issue goes away when using a external card... if it does then you know its actually the embedded interface on the motherboard or not...


    HDMI may be a digital interface but there are still ways of introducing noise into the signal streams its being used to transmit...


    Motherboard quality these days wanders around quite a bit and its not uncommon to find MB's that appear to work ok in most aspects till at some point you find some small quirk that seems no right...


    If its proven to be the MB Interface it could be just a bad motherboard (bad from a noisy point of view) that functions ok otherwise or maybe it just needs a vcc or timing tweak...

    A lot of those old Arnu boxes were basically Eny boxes so you can use a serial uart connection to alter the onboard u-boot environment to work with LE's method as suggested by Chewitt or look around for some old Eny firmware for that basic generation of those boxes as Eny makes a ton of OEM brands built around the same couple of board revisions, restoring the box with that firmware should probably allow you to regain the use of the box with current versions...


    I realize that Demetris says he's not supported the M8 in this version but can say i know that his older 18.3 and 18.4 version worked on a couple Arnu boxes based around Eny M8S (S812) seemed to work fine for a couple of buds i fixed up back in the summer... the S802 and S812 are pretty much the same box outside a couple of small things...


    Thats if your the type that just like to play and don't mind puttin time in on something that in most other ways isn't probably worth the time with boxes being so cheap these days...

    Depending on what its going to cost you and if you can find up to date software with Kodi 18 would be the biggest questions you will need to find answers for...


    Seeing as its a older unit and if your not able to build things like LE yourself, then you will have to rely on finding a build that someone is publicly supporting for the device with current Kodi revisions...that may be the biggest hurdle...


    I know from a hardware point that the Wetek Play 2 should be able to handle what you've asked as i use old boxes all the time but without current firmware you may be just better off buying something a bit newer that you know is still currently being developed on and the firmware files are more readily available for...

    Pretty much anytime one of the typical Android boxes wants to run something other then the Internal Android the U-boot environment gets slightly altered or patched to allow that altered environment to stay in effect from that point forward, unless someone once again decides to change it...


    So by using the original firmware for the box it will restore the u-boot to the factory state...


    The only other way to fix it that i can think of would be to use a serial rig to stop the u-boot when it boots and issue the commands to restore the environment that way... as long as no ones messed it up to bad and over written it there is normally a backup of the factory environment in the system, or if you know what the factory settings were you can manually set the environment from the serial terminal... its just not something most users would do as it requires setting up a serial uart on the box and using a terminal from a pc or other source to talk to the box... Doing the restore this way would in no way effect the installed Android or your personal settings as you would be basically only adjusting U-boots enviroment reqarding how it boots the box up...

    Ya thats cool...


    Still tho, even when loading CE or AE on a sd or stick to enable that those original installs on the box altered the existing factory bootloader ONCE to allow the device on reboot to now check for a bootable OS someplace other then just the internal flash... from the factory normally a box just boots up into Android but does have the ability to load outside sources which is how the Android recovery works...


    To enable a off box bootable source tho there is a script in most builds that will alter the internal bootloaders setup to check elsewhere... essentially your telling the manufacturers u-boot to check other places then just internal memory and then saving those new settings into u-boots storage area so it can be used from that point forward anytime the device reboots. So even tho your still running CE or AE on external media they at one point in their original 1st boot made those alterations to u-boot on the device...


    Once that intially happens normally you never need worry bout that anymore and just need to worry bout things like the proper dtb file for the device with its matching build...


    With that in mind what i am getting at is that the method CE/AE and LE go about making the alteration to u-boots startup environment is no longer the SAME...


    For along time seeing as historically CE/AE and others started life as Forks of LE that once any One of them were initially setup to run internally or externally the could all take advantage of U-boots altered environment...


    As CE/AE now insist they aren't really LE forks anymore their way is Not supported by Balbes (LE) builds anymore as his scripts work slightly differently... tho i quess if one wanted to spend enough time analyzing the differences a common method could be done...


    Personally even tho i have followed along for years and built all of the Distro's going back to and predating even OpenELEC which kinda started all of these types of frame works. I have a tool i created years ago that i use to create boot loaders for all of my projects on pretty much any Arm based device as i develop on ST and TI as well as the typical Amlogic or Rockchip SoC's that use Arm cores... I do RE work so i do a lot of messing around with proprietary Devices and SoC's but essentially they function in similar manners at the core...

    As far as the dtb file goes... its a standard so editing them and adapting them if you understand those files is not all that hard but i think you might be missing something else...


    As far as booting goes its the manner in which the different forks of LE go about writing to the original firmware (bootloader) to allow it to check and boot from alternative media then the internal flash...


    Initially for a while most Distro's used the same scripts to edit the manufacturers bootloader to allow the alternate loading mechanism but that is no longer the case which is what i think Balbes was attempting to point out to you, and that to make it work with his LE's and Armbian builds you need to restore to factory state and then us his newer method to create HIS bootloader edits thus allowing LE and Armbian to load properly...


    You will still need the right dtb but to get his builds to work it needs to make the device boot in a manner compatible with his builds which is what i think your having issues with...


    Someone correct me if i am wrong tho...


    Hope that clears some of the muddy water...

    sorry for the late reply...


    think of it like this.... in the old days most of the hardware/peripheral setup was done discretely by including and compiling things like drivers and support firmware into the kernel, which basically kept a kernel almost unique to the hardware you were compliling the kernel for... or in the cases of most linux distributions they created kernels that included everything including the kitchen sink built in to allow their linux distro to run on a wide variety of hardware platforms without having to compile a smaller tighter kernel...


    Over time as linux moved forward they now use a hardware database file (device tree or dtb file) that when used with loadable kernel modules allows developers to compile their basic kernel with supported modules that can be loaded in at boot time... so the dtb is a flattened database file that contains most of the hardware setting required by the device your running on...


    So the dtb or device tree file can be swapped for different devices depending on whats in that device...


    In some ways its kinda like winblows does with the HAL or hardware abstraction layer as a method of dealing with different hardware in a system...


    WIth modern linux kernels the idea now is for manufacturers and developers to get their hardware/software support implemented into the mainstream kernel structure that way moving forward any one using a device already implemented in the mainstream kernel can adjust their overall implementation of a linux os on their device or product simply by adjusting their Device Tree File (dtb) which gets read into ram when the device boots up allowing the device to find and make use off all the peripherals employed on the device...


    Theres more to the whole mechanism but thats a simplistic way of thinking about it...


    Currently that is part of what separates LE from most of the other distro's originally forked from LE...


    Forks like CE and AE and others are basically working off OLD manufacturer proprietary kernels to keep their forks running, tho currentlly some are trying to migrate upward newer kernel revisions by dragging pieces of the older proprietary kernel forward and trying to implement them in the newer kernel revisions with varying degrees of success...


    Still tho they are not mainstream kernels in the same manner as LE is trying to accomplish...


    Anyways hopefully i have not confused you, but the idea in the end is to make things easier from one device to another by allowing the Device Tree Database Files to simply be adjusted without having to rely on a manufacturer or vendors proprietary kernel to have all the hardware properly recognized by the device...

    Its the way the bootloader is being implemented now...


    Even tho intially both CE and AE were simple forks of LE things have somewhat changed with LE and how its implementing the initial bootloader has changed leaving CE different and being AE is to a large extent just another fork of CE those two are not implementing the intial bootloader setup in the same manner as LE...

    Actually now that i managed to lay my hands on a H2 and build some of the distributions like LE and CE I must say its a pretty impressive little SBC and extremely flexible when it comes to peripherals and memory...


    Anyone looking to get out from under the typical Arm gpu issues that currently plague pretty much all of the current Amlogic/Rockchip and other Arm SoC's the H2 is a serious device to look at...


    Running emu's and kodi on linux on the H2 really flies and theres nothing that i can see even coming close to touching it currently...


    Its just a bit of a pain to get still but well worth the wait if your willing to hold off for a bit till the distro chains get filled with units...

    Boxes are just old so i don't really bother playing with them anymore, but i did update one to Kodi 18.4 on the weekend for a friend and then remembered what i had done to make them still usable...


    If the box is a Maticom box then its their bootloader that is more then likely causing the issue, tho some did have crappy nands that were known to go bad but in most cases i have come across it was Matricom's crappy bootloader that would easily corrupt when messing with it and the video setup in it was for older resolutions which some screens don't pickup till the main firmware comes up (Android)...


    I forgot that i had replaced their bootloader with my own along time ago which is why i was able to keep the system updated to begin with...

    Couple of things to think about...


    If your looking at staying within the Android box market and NOT a sbc then i would say i am not sure whats really out there cheap enough with 4 gb or ram that really has real stable firmware when looking outside of the normal installed Android that comes on the box.


    If you specifically want LE and want to stay within the Amlogic realm then you will need to wait for awhile (as LE is in the middle of trying to migrate parts of their core up to the mainstream (linux) which has lead to them not really supporting Amlogic in their current development tree while this process is going on...


    With that said tho... if your able to handle building their sources on your own theres no reason their current build can't be patched up to build a Amlogic using the newest Kodi (Leia) and on one of the older none 5 kernels... Its just not something i think any of the LE guys are going to do so you''ll be on your own... I know i have done it multiple times and i know others that are still doing it for their own purposes...


    If you want LE without the hassle of building yourself then you probably need to look around here at NON Amlogic boxes to see whats available,,, Rockchip, Allwinner or Rasp maybe able to give you what you want...


    Things are pretty fluid these days as people try and fix or find solutions to the GPU issues which currently plague the Amlogic and Rockchip SoC's when it comes to hardware acceleration to any Non-Android OS running on ANY of those boxes and there is no way of predicting if or when those issues will all be solved at this time...


    If your trying to get out from under those conditions then you need to look at other things like the H2 which is a SBC or some other Intel based device thats not prone to the GPU issues...


    In some ways depending on what you want to do it may be better to just stick with a older box that actually has Leia support that works for the time being till things...


    Finally as others have said there are LE alternatives, but to be honest they aren't perfect either and if your a plug-and play type of person they can be troublesome as well...

    It kinda comes down to how much playing around you want to do...


    The shield is ok and pretty stable for what you get but the downside is its not really all that open to development...


    Probably the best bang for your bucks would be a 4 gig N2 or RockPro64 sbc board as they are pretty flexible but the downside with both of them is they are still heavily under development when it comes to the hardware side of the GPU stack... Things are getting better with both but i would suggest to do a bit of reading on both before deciding which way to go as one is Amlogic driven while the other is Rockchip and depending on what your intent is the teeter-totter is not perfectly balanced...


    As well theres the Raspberry 4 (i can't say much about as i don't own one). the same goes for the Allwinner driven devices...


    The other option would be to look at something like the H2 which would get you out from lack of GPU hardware support issues found on both the Amlogic and Rockchip devices as the board is Intel based (more like a regular PC), but again its new and still being developed...

    With the AE builds you may have to try a different more suitable to S802 file as the compiled in wifi maybe different....


    The S812 and S802 are close in most ways but the wifi chipsets maybe different between them and even board revisions within the same SoC not always had the same chipsets...


    You could try using a different dtb from within the same build with the file that your trying and see if that helps...


    That is assuming your using the X8H and not the X8H-plus.... ( the plus is S812)....

    Not sure your going to find a current regular LE anymore as that box if i remember right is a older S905 box and current Amlogic's not really supported in LE these days...


    but with that said there should be some other builds around that work on the older S905's... You may have to look for a alternative build that has got the current Leia version of kodi in it and play around with the dtb files of that build to find the right one that works with it... I don't have any of that particular device but have a bunch of older original Netbox A95x which was the S905 (not the x) and compiled LE to run on them aways back and have seen builds by other developers make builds for other boxes with the same SoC.. you may just have to look around a bit.

    with the limited info you've provided i would say this...


    If your just trying to update Kodi on Android then you need to just find the newest Android version of Kodi and do it within Android like a normal app...


    If your talking about the version of Kodi within LE then you will need to find the newest version of LE for your particular box and go from there...


    Keep in mind the with Os's like LE the version of Kodi is integral to LE so to update kodi itself requires the whole OS to be upgraded...


    Assuming your talking about using Kodi from LE then you'll need to know what box your using and start looking around here for the appropriate version of LE for you box...

    I am not sure if this will help but there is another build called EmuELEC that is built from CE sources only without Kodi as its a games type of build and i am pretty sure that in his Amlogic-ng project he has incorporated qt-everywhere version 5.13... I know the buiild works because i have built both the Amlogic and Amlogic-ng and tested them on devices because his Emu's in it are some of the best working ones i have come across this year so far...


    Just pointing that out as its a working example i know of that has no kodi in the build and is using QT-Everywhere... Its done by shantigilbert...

    Well thats not exactly true.... Discussing hacking of DRM's i don't think is something allowed here but anyone that truly understands Arm's Tee and enough about emulating decrypt/decode routines would disagree with you... its more about no one wanting to take on the issues of messing with DRM protection out in the public domain...