Posts by buzzmarshall

LE is kinda in a transitioning mode while they work towards getting things up on the mainstream sources so there is a bit of slim pickings in most the amlogic stuff right now while their guys are busy...

There are a few around tho that have their own forks of LE so they can maintain some of the Amlogic boxes, just not sure who's got what so you need to do a bit of checking around.

I know that box is able to run the newest because i have matrix and the 18.5 running on it and it works fine, the issue is just things are kinda quite here in the Amlogic area which will probably change someplace down the road.

Trying to update the kodi version on your existing software is more work then its worth as you might as well just do your own build if your going to mess with that.

The patches work fine on the Arm devices but when implementing them on a X86-64 build pthreads are not normally supported unless you alter the build system to put one of the typical wrappers around pthreads as windows doesn't natively support it as far as i know.

Don't get me wrong as i am not saying it won't run.

Hell i have matrix 19 running on older S812 and up.

I am just saying that if your not self sufficient in developing and are like most that rely on other developers for firmware then even a free box without current software really is not worth anything other then a parts board to be played with or thrown on to your pile of old devices.

Out of all the different developers out there to a large extent they all are based on OE and LE and as such pretty much make use of the same build system that each fork has altered for their own purposes and the amount of support for the older boxes is getting smaller all the time.

Currently with LE focused on moving linux to mainstream and off the old proprietary BSP's and help push Kodi thru the python 3 upgrade they have chosen to support a smaller pool of devices while transistioning... So most of the other Distributions are trying to support some of the older devices while still supporting the older propriatary BSP's for the devices they have chosen to support.

All I was saying was that unless your willing to learn or already have the ability that you will probably have to either rely on someone else's firmware and if you can't find any then you will be at least at a minimal level have to take some existing build and hope to mod it enough to get it to work. Maybe just a dtb change maybe more...

So as much as $15 bucks is a good deal you may not have much of a choice other then running Android and then Kodi as a app, which to me is something not worth the effort.

I have been running Linux on these devices going all the way back to the Dream devices as the idea of running Kodi on a OS that is basically a touch screen OS is just dumb in my opinion if your trying to get the best performance out of Kodi. but hey to each their own...

But just to be clear i never said it can't or won't run.

Sounds like a deal... But... there is always a but ...

Storage space is not as big a concern depending on how much crap you keep on the box...

Personally i would never buy a box these days with less then 2g sram as more Sram is always good and besides pretty much the only place you see 1g devices these days is in New Old Stock that the crappy dealers will try and dump just to get their costs back.

Its not that it Can't run LE or any of the LE clones/forks like CE/EE/AE or others but its already getting hard to find developers releasing for older devices so no matter what the deal maybe it could still end up as a waste of money if your not into taking things into your own hands development wise.

Kodi has already moved to 18 and in the near future will be going to 19 and unless you want to just settle to keep it going on 17 and python 2 or maybe if your lucky enough to find a version with Kodi 18 your choices will keep getting smaller.

But if that is all you expect out of the device then it may serve your purposes...

No Probs...

No misunderstanding on my part as i understand the term but kinda ignored it for context as i am assuming his reference is to the current open source developers trying to create a reverse-engineered open source solution or possibly from some other platform using the Mali's which maybe hacked to make useful...

Sorry, i made the assumption by your interest in them that you were maybe of the type wanting to go down the development rabbit hole and was just trying to point out that blobs and info can be found if one wants to look and that finding the DDK even a older one is a good source of info for anyone trying to create blobs for their own non public use to test on..

Blobs are a pain in the butt but doable, but they are ok for the big factories that can absorb their costs whenever they need them created but the small Linux developers can't absorb those costs every time they want to upgrade their device leaving open source solutions as the only real answer which is why i make it a point to follow the open source development to see how things are going...

I have watched a lot of start/quit linux open source attempts over the years but this last year with the current group of developers has really kicked the ball closer to the net , its impressive and this time round appears to show the key dev's involved are in for the long haul which is great.

sorry for the confusion...

Assuming he's referring to private stuff given to them but still if you want to put the time in you should be able to locate alternate Mali uses OTHER then Amlogic, Rockchip and the rest we typically see here...

If your good with ftp search engines and figure out the search string to look with, you will find there is more sources of information on the Mali's then just the ones here everyone typically associates the Mali's with...

The news feeds (uucp) is another place to look for info...

Blobs are floating around tied to various DDK's and linux revisions, and if your resourceful enough you may even come across a DDK and work towards creating your own blobs... just understand doing so has some legal implications that you may not want to step into... (hence why most of this is private and will stay so)...

Thing is tho if that stuff is used for informational purposes there is nothing that says you can't use it and other info to create your own without using the DDK which technically is arguably without the same legal implications of using a unlicensed copy of the DDK... you will probably need some rudimentary Assembly skills on Arm as well...

great post... very informative and actually shows there has been a decent amount of forward progression

your right about the deinterlace on Amlogic... its one big mess and a working one can definately be done with a much smaller footprint and to be honest wasn't as much work as originally thought, just a bit time consuming...

Motherboards can be funny animals as they all pretty much work in general but then in a lot of the cheaper designs there is usually a few little quirks that can pop up that maybe for general use go mostly unnoticed by users... sometimes just moving things around inside the case and where cables are crossing things can introduce things into systems... some of the cheaper boards can be picky that way...or then again it could just be a bad board to begin with...

Things like bad caps on a board which is not all that uncommon can cause weird noise issues and intermittent things like booting issues... I recap boards all the time and have seen even some more expensive boards with caps that are drying out that lead to all kinds of issues...

Hopefully its just something simple like moving some cables around...

One other thing i would make a comment about is that i am assuming you swapped out the boards yourself and if so make sure the grounding posts are not touching on anything other then the ground landing pads on the board... its the grounding ring (pad) around the mounting hole on the board where the mounting screw holds the MB into the case... Some boards that solder ring built up around the hole is heaped up with more solder then needed and then when tightening the screw down it gets squeezed and widens out till it touches some board trace that laid real close... Sometimes when things like that happen its not bad enough to stop the board from booting but causes a bunch of intermittent issues...

Can you boot any thing via USB on that workstation or is it just the LE stick that wont be found...

In the bios make sure to Disable the Secure Boot for Legacy otherwise you may not see the usb option...

If your actually able to boot stuff from USB then as Klojum suggested try a different writing app... You may want to check and make sure that the machine has the last released bios for it installed as there were a few fixes in the last release that fixed a few things, some of which seemed to help booting from a wider variety of sources...

In general tho those machines are not the greatest things to play with things like Kodi as the machine is more designed and suited as a workstation for something like CAD... Last time i ran kodi on one of them was back around the days of Jarvis-Krypton and even then they were kinda buggy and i had to swap out the video card for something more mainstream and then found it didnt play nice with the ECC memory till i swapped it for a different brand...

Not to put a damper on your idea and i am sure with enough playing around you will eventually get it to work but depending on what options are on the machine you may end up playing around with a bunch of things trying to get it to work right... Their were great machines for what they were meant to do but can be touchy trying to get them to run what you want and being a HP makes things a bit worse as like IBM they like to do things their way...

I still have a couple of them here with maxed out cpu's and memory and was using them to run Unity and some PCB Cad software but finally gave up trying to keep up to date versions of software on them as they are just to much work to run newer software on them...

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

Actually the 2 projects are not as close as they used to be in some areas... CE and how its messing around with the U-boot env are not the same as LE and some others... and as far as dtb's go its best to use the ones that go with the OS as different builds are not always using the the same Kernel's...

As chewitt suggested its probably best to bug the CE guys...

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