<}8]>
so if i read correctly, an odroid-n2+ running coreelec is the go-to setup for 4K HDR. and libreelec is a fork of coreelec? is it safe to say LE is as suitable for 4K HDR then?
fraggle_boate has quit [Ping timeout: 260 seconds]
held has joined #libreelec
<buzzmarshall>
hm... nope... CE is a fork of LE and still stuck using propriatary vendor bsp's
<buzzmarshall>
LE has been the leader in moving towards implementing mainstream kernels
<}8]>
hmm, is the vendor bsp's where the 4K HDR support is coming from?
<buzzmarshall>
not saying anything bad about CE but basically thats the difference in their paths of development
<buzzmarshall>
i no longer build CE sources but would say thats probably the logical assumption
<buzzmarshall>
whatevers in the vendors bsp's is whats being inherited into their development
<buzzmarshall>
CE is really more about trying to provide a working solution for a lot of devices while LE is moving up so at this time in a lot of ways is probably a better fit for the general public depending on the device and what your expectations are
<}8]>
ive been waiting forever for linux to catch up with HDR support but thats going slower than a herd of turtles. we're adding a 4K tv here that will need kodi and im not going to invest in a client that cant do 4K HDR for it
<}8]>
i read the "START HERE - Pick the Right Kodi Box (updated August 2020)" post in the forum and that suggested the odroid-n2+ running coreelec
<}8]>
also read some misinformation that LE was a CE fork, which is how i wound up here. also couldnt find any CE irc channel
<buzzmarshall>
i think a lot are using CE on the devices they currently support trying to provide a working system thats as close to the features the device supports which means they are kinda stuck on the vendors bsps
<buzzmarshall>
so for people that just want a plug and play solution its usually best to talk to others that have working systems giving the features your looking for rather then getting caught up in a bunch of bs marketing crap
<}8]>
i was really really hoping linux would get HDR support in the kernel before i actually needed it
<buzzmarshall>
in the end it probably will but its a long road and to be honest the open source coders have come along way
<buzzmarshall>
but in some ways there still stuck in some corners as the biggest hurdle is without a proper known register set and how things really work at a hardware level most of whats being done is by trial and error
<buzzmarshall>
it can and has been done in private circles now for awhile but that will never see the light of day as most of the ones doing so are not interested in any way of helping the SoC makers when they could easily pony up to the table and provide proper linux support
<buzzmarshall>
most of the SoC makers have no real interest in supporting Linux even tho more of the enduse of their devices are moving that way
<buzzmarshall>
the advent of the sbc's has really helped stimulate the linux side of things but still pretty much of all it is being done by volunteers with a bit of commercial support from a few sources but its just a long time consuming process
<buzzmarshall>
the other thing is kodi is also kinda in the middle of making some jumps forward with the impending matrix release while most of this continues to play out
<buzzmarshall>
so for alot CE and some of the other forks that are kinda trying to provide the best working solutions on their currently supported devices is probably a good choice for some
<}8]>
was away for a min, lemme read
lolek has quit [Ping timeout: 256 seconds]
<buzzmarshall>
np... i was actually off checking something ive got compiling anyways lol
<buzzmarshall>
basically thats just my overview of where things are currently at... but i am sure in the end it will all be there unless the open source projects end up folding which this time around i cant really see happening as the current group of players have actually made good headway
<buzzmarshall>
and seem to be in it for the long haul
<buzzmarshall>
but the downside is there's no real way of saying when
<}8]>
it sucks that stuff works in private circles but i fully understand why its staying that way. theyre right, soc makers could contribute but unfortunately theyre not motivated to do it. you'd think there would be longer vision with those companies in that the more widely supported their hardware is, the more mainstream it can become
<buzzmarshall>
i agree especially in light of the sbc's which really aren't tied to any particular os
<vpeter>
The difference is do you want to use something today or tomorrow (read in a year or 2) :)
<buzzmarshall>
i get the whole android box market where it started but thats kinda a dying market in some ways
<buzzmarshall>
personally i see it as pure greed on the SoC makers part and because they know theres a huge growing market interested in linux on the device they are being stupid and leveraging against using the free coders to solve the issues
<buzzmarshall>
and mostly all the sbc boards are all in kinda the same boat as most things linux work fine until you come up against the gpu related things and then they are mostlly all in the same boat
<buzzmarshall>
and at the rate of new sbc's coming out and the increasing cost of some of the devices by the time you buy all the parts your getting into the price range of other hardware where gpu drivers are more readily available in regards to linue
<buzzmarshall>
sorry linux
emOne has joined #libreelec
<emOne>
buzzmarshall: hello
<buzzmarshall>
ive bought so many different devices in the last few years and find them all kinda in the same boat grpahics and media wise and was hoping the H2 would be a improvement being its intel based but ended up droping that as i think HK's quality has dropped alot in the last year or so
<buzzmarshall>
hey you... i keep missing ya
<buzzmarshall>
ive gone thru 3 H2's in the last year or so and all of them have had issues at board level as the reflows on the boards were all crap with parts not down right and even a couple of bridged connections
<}8]>
im honestly not sure why all (or it seems like all) gpu's are treated like a top secret technology. advanced gpu's with custom algorithms, features, etc, sure... i get that.. but gpus that basically just provide video output and decoding. why is that so top secret?! does quality differ that vastly from one h264 or hevc decoder to the next?
<buzzmarshall>
i do board level repair all the time and was suprised to see their quality drop
<buzzmarshall>
Company's like Arm make their cash basically from licencing fees and the support they can charge following that revenu stream
<buzzmarshall>
and with GPU's being a hot market aren't going to let up on that
<buzzmarshall>
and for whatever reasons most of the mainstream SoC makers keep sticking to the Mali cores for example
<buzzmarshall>
and are not interested in paying arm to have licensed blobs made for anything other then the canned version of Android they provide the downstream device makers
LossAngeles has joined #libreelec
<buzzmarshall>
so the only way around that is to reverse engineer the firmware inside the device core to see how the gpu firmware is implemented in the wafer
<buzzmarshall>
thats one part and is doable but then the real stopper tho is who wants to hang their butt over the boat to expose that to the open public
<}8]>
its pretty frustrating from a user standpoint, and im guessing borderline infuriating for devs who just want to help provide users with a good experience
<buzzmarshall>
ya for sure
<buzzmarshall>
ive been putting linux on arm based devices since before any of these jeos systems sprung up and even tho over the years a lot of things have gotten better and easier when it comes to linux on the device
<buzzmarshall>
the core issues are basically still there
<buzzmarshall>
even simple hevc has become a issue
<buzzmarshall>
i think you'll see that appear on the rpi4 1st as stateless will probably happen before statefull does
<buzzmarshall>
but even with it and broadcom the gpu is still a protected enviroment when it comes to open source
<}8]>
:\
<}8]>
i think whats equally lame is theres no hope of things changing. at least it sure feels that way
<buzzmarshall>
personally i still question why the raspberry guys stuck with broadcom because of the videocore firmware
<buzzmarshall>
thankfully tho theres a bit more leaked info on it floating around then the arm stuff
emOne has quit [Ping timeout: 246 seconds]
<buzzmarshall>
in some ways i agree as its kinda a lossing proposition as the device and SoC makers have a cycle of releasing new products now thats fast enough that by the time the open sources start to appear those devices are way obsolete
<buzzmarshall>
but the cycle has acceleratetd the public into buying new stuff leaving most of the old stuff in the dust
<buzzmarshall>
lol
<buzzmarshall>
personally i still run a couple of dozen old S812s as media boxes and they work fine for my purposes
<buzzmarshall>
they are just running on my os which i keep updated with the new kodi that i constantly build
<buzzmarshall>
ive got all the newer boards but find for what they cost and actually deliver its just not worth getting caught in the buying cycle
<}8]>
thats something else too - a new hardware release doesnt automatically make the current hardware outdated, especially when it comes to media/htpc .. its not like related technology is on full speed ahead in that department
<buzzmarshall>
the S912 is a decent device as well
<buzzmarshall>
for sure... especially for media boxes
<}8]>
anything that does 264/265 4k is going to be good for quite a while still
<buzzmarshall>
to be honest the only real area on the media box that should need to be updated is the codec end of things as new ones appear
<buzzmarshall>
so why all this new hardware is even needed is to me a waste
<buzzmarshall>
a lot of its based on 64bit which is still basically useless to most in the userland area
<buzzmarshall>
if it was my call to direct where the open source learning and testing was being done it would be on the older devices as theres more known and floating around and once thats shored up then start looking upwards
<buzzmarshall>
but like most things everyone wants the newest
<buzzmarshall>
lol
<}8]>
whats the next move? av1? and how long is that wait going to be? i agree, the steady flow of new hardware is a waste
<}8]>
im not a dev unfortunately but i fully agree with that model! focus on perfectly capable hardware with the most knowns. get that solid, then move on to something newer. i'd rather have hardware thats a couple years old but still suits my current needs and is solid, than have the latest `precious` that doesnt even work right, ....but its the latest!!!
<buzzmarshall>
true... really the whole point originally was to have simple hardware to handle media and it seems like the hardware level has expaned 10 fold while the actual media requirements have maybe only doubled
<buzzmarshall>
lol
<buzzmarshall>
but once again its the makers herding the general public as theres not much money in it for them if people arent buying devices at this accelerated cycle
<buzzmarshall>
there was for awhile soem interest in releases of better working software for the older devices being introduced because most of the mainstream releases from jeos setups like OE and LE and the rest of the forks are basically only interested in the newest devices but most of the ones i know that were interested finally backed away from the idea because of the idea of support and the time involved to do that
<buzzmarshall>
so those setups ended up more in private circles where no one has to deal with the headache of support
Gnjurac has joined #libreelec
<Gnjurac>
if i go factory rest will that restet my nfs mount drive too ?
<Gnjurac>
duno what i did but now it wont show any shows or movies
<Gnjurac>
just asking if i SOFT or HARD reset it i will have to configh again that mount nfs drive right?
<}8]>
i wish that was more open, at least to people who understand that X is what works and theres no support beyond that. basically if you want to get Y hardware and run X, you can do it, but thats where it ends
<buzzmarshall>
ya i agree as there is a lot of mis information that gets spread around and tends to make things confusing for users that really just want to know what to buy without getting in much deeper then looking for something that meets their needs
<buzzmarshall>
part of the problem stems from the whole social scene that tends to be part of whatever few forums are around where there are a lot of types that sit and talk without actually knowing as they don't really do much developing on their own other then repeatin what some others tell them
<buzzmarshall>
which is fine to a point but then when someone else with no social standing on those sites starts to speak they usually getted slamed by one of the so-called resident guru's and end up just leaving rather then fighting back to try and contribute
<buzzmarshall>
thats a real issue and because of it has caused some really knowlegdable people to back off and not bother
<buzzmarshall>
if people would just stop and think once and awhile and think logistically as to how some of these social guru's seem to find enough time to hang on a site around the clock and still find time to work and have a life and actually do any real development is beyond me
<buzzmarshall>
lol
<buzzmarshall>
some of us gave up on that years ago as its a choice one has to make
<buzzmarshall>
its either hang around socially and try to be the guru or go and do your own thing within a smaller group and waste very little time publicly
<}8]>
i hate when that happens! knowledgable people dont grow on trees so i valued every one who contributes. but, i also know what its like to be that person and spend too much time arguing with people who have no clue what theyre talking about. its annoying as all hell and you can definitely get to the point of `why bother?`
<buzzmarshall>
sites like FT is the perfect example
<}8]>
the community doesnt gain anything by having couch experts or people on a quest to be forum-popular
<buzzmarshall>
it happens tho when the public starts to worship the main yappers who when stumped can't advance the topic and then when someone that no one knows comes along and ends up getting flack they just leave
<buzzmarshall>
the other thing is for most of the guru types theres incentives to act like that as usually in these games there the one that are getting all the freebies and the rest of the perks so they tend to want to maintain that
rubdos has quit [Ping timeout: 240 seconds]
pragmaticenigma has joined #libreelec
rubdos has joined #libreelec
<buzzmarshall>
that in turn usually is another reason the smarter ones tend to stick to their own and form in smaller private groups
<buzzmarshall>
at least when they work together they are pretty much all treated with respect and evenly
<buzzmarshall>
publicly it just doesn't work like that
<buzzmarshall>
know one has enough time in the day to take on both sides of the learning curve to do both things
<}8]>
youll always find too many chefs that dont know how to cook in the public places
<buzzmarshall>
lol
<buzzmarshall>
for sure
<buzzmarshall>
i stick around here just to keep up with where everything is kinda at and long since gave up on any of the other sites as they are pretty much just socially driven and designed to keep their social structure
<buzzmarshall>
here with LE its at least working towards moving forward which to me is most interesting personally just to see where they are
<buzzmarshall>
other then that i don't bother anymore
<buzzmarshall>
the other developments like CE or AE and the rest hold no interest for me as their not really moving and in the end will only end up taking what gets developed here and incorporating it in the end anyways
<buzzmarshall>
not that i am saying there is anything wrong with that
<buzzmarshall>
it just holds no interest for me or the others in the small group i generally work with
<}8]>
if more users get working setups and theres no bad blood in the process, i guess its fine. not a perfect scenario by any means but if it isnt causing any real conflict
<buzzmarshall>
true
<buzzmarshall>
if all the distro's took the same direction as LE then there would be less actual working setups out there
<buzzmarshall>
personally i am glad that LE decided to go this road as me being a bsd/linux guys since linux started have always wanted to see a migration to the mainstream for these types of developments for along time
<}8]>
at the end of the day, a healthy (public) community needs users with working systems. as far as i know, and im certainly not well-informed on the subject, there isnt any real distro beef
<buzzmarshall>
for sure
<vpeter>
Didn't know LE is making everything in-house :)
<vpeter>
And as I already wrote the main point is to have working solution. Only that matters.
<}8]>
for kodi, im purely linux here with self-compiled kernels + kodi. ive patiently been waiting for linux to catch up with 4K HDR and have put off buying a new main tv for it. we did a remodel downstairs and are adding a tv soon. i refuse to buying a 4K HDR tv and invest in a non-capable kodi client for it though. my preference isnt to get an odroid-n2+ or similar but right now that seems like
<}8]>
the best option of only a few
emOne has joined #libreelec
<}8]>
my goal with this setup is 1) it works and 2) is at least pretty stable. that should get me a livable WAF lol :)
<emOne>
HEVC is a must if you want to use your board for media imho
<emOne>
Is there somewhere a progress tracker to see how much of the HEVC code has been reverse engineered?
<vpeter>
And if we talk about LE mainline approach: normally would be to develop new platfor side by side and not killing it for how long? 2 years and still not done.
<emOne>
Hello vpeter
<vpeter>
hi back to you too :)
<emOne>
Just ask the developers of HarmonyOS to reverse engineer everything that isn't working
<emOne>
I am sure they will do it in a day just so their os works on those devices
<buzzmarshall>
sorry was grabbing a byte to eat...
<emOne>
Grab a kilobyte instead :)
<buzzmarshall>
lol
<buzzmarshall>
hevc actually isnt all that bad as its kinda now just a matter of creating and implementing the decode into the l4v2 and the rest of the supporting packages
<buzzmarshall>
rpi4 using stateless will probably come first as theres a bit of framework stuff that will help
<buzzmarshall>
the statefull approach tho requires more work
<buzzmarshall>
privately i know in at least 2 circles its already done
<vpeter>
I got a big smile when I read something like "now just a matter of creating and implementing" :D
<buzzmarshall>
publicly i don't think is that far off tho
<buzzmarshall>
lol
<vpeter>
It reads so simple. The actual code is probably not.
<buzzmarshall>
ya thats true as most things tend to sound simpler then they really are
<buzzmarshall>
but a lot of that depends on the perspective of the ones approaching the problem
<emOne>
That is pretty awesome that HEVC is finally going to be released
<buzzmarshall>
people that have spent most of their years reverse engineering things tend to approach things differently then most coders
<buzzmarshall>
coders or mainstream guys see things in a different light in most cases and it tends to make the tunnel your looking down narrower
<buzzmarshall>
most re types are hardware assembly level guys that work much slower but approach things differently
<buzzmarshall>
its a much more specialized area that even at school level tends to be more of a historical topic as most coders these days are taught the technolgies that will get them decent jobs
pragmaticenigma has left #libreelec ["Leaving"]
<emOne>
Assembly is something very special
<emOne>
I admire people who code in assembly
<emOne>
The patients for it is incredible
<emOne>
Patience
<buzzmarshall>
and with all the format advancement these days with stuff getting smaller and denser any coder that doesn't have the hardware chops is limited in their approach
<emOne>
Quite naturally
<buzzmarshall>
when i started anyone coding didn't have much choice as the higher languages werent where they are now
<emOne>
As cpus and gpus have gotten excessively powerful there has been a lot less to worry about when coding about
<buzzmarshall>
especially on the embedded stuff
<buzzmarshall>
if you didnt understand at least the basics of the hardware and assembly you weren't going to get very far
<emOne>
As a coder these days you don't have to worry about how much ram or power the system has
<buzzmarshall>
now adays its more of a lost art
<emOne>
Because System memory and power is abundant
<buzzmarshall>
true
<emOne>
Coders have to rush their programs to meet deadlines
<vpeter>
"you don't have to worry about how much ram or power the system has" - depends. I deal with ram usage daily :) Almost same for cpu power.
<emOne>
There is no time for optimisation.
<emOne>
Hehh
<buzzmarshall>
my higher level abitlities suck as i always see things from a register point and assembly is what i know
<emOne>
What do you code in?
adhux0x0f0x3f has joined #libreelec
<buzzmarshall>
any of the embedded stuff i always work at assembly level
<emOne>
I suppose in c and c++ you have to worry about garbage collection,,, but there is boiler plate code for the
<emOne>
that
<buzzmarshall>
and C
<emOne>
Oh wow buzzmarshall
<emOne>
OK so very low level
<buzzmarshall>
i understand most of the higher lang but am not proficient as i don't do it all the time
<emOne>
All the atmel chips and embedded chips are usually C I think?
<emOne>
Unless ofc you prefer assembly
<buzzmarshall>
i also understand a lot of fab level stuff as i have done a fair amount of decapping and messing around over the years
<emOne>
Assembly is pretty hardcore
<emOne>
That is awesome
<emOne>
Could you design a cpu?
<buzzmarshall>
when i started things were 8bit so it wasnt that bad
<buzzmarshall>
if i was younger and starting over theres no way i would be playing at this level
adhux0x0f0x3f-- has quit [Ping timeout: 240 seconds]
<buzzmarshall>
technically i am more of a hardware guy and see everything as simple switch which makes assembly or microcode easier
<emOne>
But there have to be people who can understand low level code
<emOne>
Unless AI will do it for us
<buzzmarshall>
things have just got denser and faster over the years but essentially its all still just a bunch of switches moving from registers to other areas of memory
<emOne>
Is it like suduko?
<buzzmarshall>
sure theres lots that learn and use low level these days its just more of a specialized skill set
<buzzmarshall>
and the low level tools are much better these days as well which helps isolate some of the abstraction layers
<buzzmarshall>
for me jtag is the cats ass
<buzzmarshall>
understanding boundary scan tools and how to create and use them shows pretty much everything anyone can want to fish out of something
<emOne>
Boundary scan tools?
<buzzmarshall>
your still stuck with things like encryption but the answers to even most of those hurdles are still always inside the device
<emOne>
Just like in those smart cards
<buzzmarshall>
jtag or boundary scan tools are fab level tools that allow for all the nets on the board to be tested
<emOne>
Would those be allowed for arm socs?
<emOne>
Or are those closed because of the licensing business model?
<buzzmarshall>
pretty much any processor these days has them as thats how the fab houses test the physical wafer
<emOne>
I am guessing in arm socs they're probably unofficial or hidden
<buzzmarshall>
nope its a standard
<emOne>
But couldn't you just learn about the contents of the blobs this way?
<buzzmarshall>
its a communication protocol that lets software test the device at a net level
<emOne>
Or sniff the activity to learn how HEVC decoding works for instance
<buzzmarshall>
eg on say the S812 and the mali which is closed source
<emOne>
Like a debugger?
<emOne>
Mhm
<buzzmarshall>
it actually lets one see how the blob talks to the core hardware
<buzzmarshall>
from that point the api starts to be able to be figured out
<emOne>
Aha so the first step I suppose
<buzzmarshall>
dumping the blob and the internal registers on the SoC makes some of the quess work easier
<buzzmarshall>
thats a simplified statement and things are alot deeper then that but thats the basic idea
<buzzmarshall>
currently you've got coders trying to figure out and create open source software for the gpus
<emOne>
Just run inside the arm hq with a pistol and scream "give me the frikking codes to the blobs!!!" "THE BLOBBBSSSSS!!!!" xDDDDD lol ;D
<buzzmarshall>
part of their stumbling block is trying to figure out what all the registers are
<buzzmarshall>
and then how the flag bits work
<emOne>
Joking obviously.... Because they would obviously have no idea what you're on about lollll
<buzzmarshall>
but they are having to make alot of quesses by trial and error and use whatever info they can glean from other stuff
<buzzmarshall>
lol
<emOne>
It is such a painstaking process geez
<buzzmarshall>
the blobs are basically the code provided by Arm to say amlogic for the Mali 450
<emOne>
I think a patreon needs to be started so these reverse engineer guys can do this as their main task
<buzzmarshall>
its the part that is tied to a specific version of Android and cant be changed
<emOne>
Right
<buzzmarshall>
Arm creates that with what they call the DDK
<emOne>
Interesting
<emOne>
What's that?
<buzzmarshall>
that way they can retain the source and sell the firwmare to the downstream
<buzzmarshall>
so the SoC licences the blob for the device they are building and selling
<buzzmarshall>
in this case its always for a specific version of Android
<emOne>
I mean it isn't the best way to prevent piracy
<emOne>
Everyone can just start using that kernel version
<emOne>
And pirate the blobs
<emOne>
From vendors who paid for the blobs
<emOne>
And we will all be stuck with one old kernel version
<buzzmarshall>
so for linux use the original hack required someone to create a method of using the Android provided blob and writing a wrapper around to try and make use of it under linus
<emOne>
Ooh
<emOne>
Nice
<buzzmarshall>
it kinda works but has support issues as android and linux arent the same
<buzzmarshall>
alot of chipsets are written like that
<emOne>
I thought it was tied to the kernel version no?
<buzzmarshall>
wifi and networking
<buzzmarshall>
this lets the owner of the sourcecode retain control while making their devices usable downstream in whatever the downstream maker is creating
<emOne>
I recall chewitt posting in the LE forum about the mt7668 WiFi chip
<buzzmarshall>
ya those blobs will be used by the kernel
<emOne>
So couldn't you just use the kernel version with Linux?
<emOne>
That is what ce is doing
<emOne>
They're using the blobs but are staying on the old 4.9 kernel
<buzzmarshall>
if one were to look at the linux kernel you can see at some levels there is no real source code for some driver level firmware
<emOne>
In fact that is probably why everyone is staying on 4.9
<buzzmarshall>
instead theres a blob
<emOne>
This is quite a recent phenomenon though
<buzzmarshall>
they just get compiled into the linux sources when they build
<emOne>
Because Linux has always been about the open source nature
<buzzmarshall>
been like that for along time
<emOne>
Nvidia was the first to close source their drivers
<emOne>
And they did get a lot of hate for it from the community
<buzzmarshall>
basically other then some other philsophical things the primary dif betweeen bsd and linux is in its licencing
<buzzmarshall>
bsd allows for someone release public open source wihtout exposing all of its sources
<buzzmarshall>
apple and even android are like that
<buzzmarshall>
bsd style of kernel controlling a linux style userland
<emOne>
Apple is like that but they still publish source code to Darwin AFAIK
<buzzmarshall>
in androids case its kernal is all about supporing the java dalvic peice of crap
<buzzmarshall>
apple is darwin
<buzzmarshall>
some of Apples stuff is under a nda
<buzzmarshall>
some of the stuff is in the form of blobs
<buzzmarshall>
the stuff in blobs is basically just a binary thats being used by the rest of the system
<emOne>
Well most of it
<emOne>
Yes
<buzzmarshall>
in the case of most of these devices around here
<buzzmarshall>
its Arm and their Mali product line
<buzzmarshall>
they don't give those sources out to anyone
<buzzmarshall>
they only provide blobs
<emOne>
+ there are talks of arm being sold to nvidia
<buzzmarshall>
the rest of the Arm software is opensource
<buzzmarshall>
thats why the gpus are always the issue here in reqards to linux on the device
<emOne>
So they're sure as hell not going to open source those blobs before any acquisition
<buzzmarshall>
thats right
<emOne>
And nvidia is not a big fan of open sourcing drivers either
<emOne>
Which isn't good news for the community
<buzzmarshall>
so the opensource guys here are trying to create software that will talk to the Mali hardware cores without any knowledge of how things work
<buzzmarshall>
which is why its time consuming
<emOne>
Have they ever heard of decompilers?
<emOne>
I am being sarcastic
<emOne>
But why would decompilers not work?
<buzzmarshall>
hm... think of it this way
<buzzmarshall>
think of the mali as a cpu that like a cpu has a instruction set to control it
<emOne>
Mhm
<buzzmarshall>
so even if one were to observe the commands going into it via varouis debug tools
<buzzmarshall>
you would still not know whats actually goin on inside that cpu without knowing what and how the instruction set works
<buzzmarshall>
kinda like feeding something into a black box and getting predictable output out of without knowing its hardware internally
<emOne>
Hah I was just thinking about black boxes
<buzzmarshall>
so Arm uses a DDK for the Mali to write and create a blob that knows how to do the talk and walk the walk
<emOne>
So in this case both the cpu and blob is a black box that talks to each other?
<emOne>
And all we can do is capture the traffic going between the black boxes?
gouchi has joined #libreelec
<emOne>
Or am I missing the point slightly?
<buzzmarshall>
the only real way to truly understand it would be at a fab level to decap everything and take it layer by layer apart to create a verilog or vhdl file or a bunch of micrograhps
<buzzmarshall>
they actually create the logic blocks at a hardware level and from that you can derive its basic functions
<emOne>
Do cpus come in many layers?
<buzzmarshall>
most of thats now not really legit dependin on the end purpose
<buzzmarshall>
sure...
<buzzmarshall>
everything logic wise is really nothing more then cells
RedSoxFan07 has joined #libreelec
<emOne>
Transistors right?
<buzzmarshall>
ram, processors all of that are electronic structures made at fab level
<emOne>
Is it similar to silk screening?
<buzzmarshall>
so when something is designed in the software tools they produce the files required by the manufactureing to create the hardware
<emOne>
Right
<emOne>
And these days the circuits aren't even manually designed anymore
<buzzmarshall>
tools like vhdl or verilog are some of the more common tools that create the design files for fab level
<emOne>
Instead it is coded through a verilog
<buzzmarshall>
over the years they have gotten much better which is why things keep geting smaller and faster
<emOne>
It is pretty cool how in the beginning the circuits were designed manually as far as I understand
<emOne>
But now they're designed by computers
<emOne>
And it is only necessary to code the verilog
<buzzmarshall>
sometime just google silicon chip design and you'll find tons of sites with pictures or micrographs of all kinds of chips out there
<emOne>
But the computers figure out the best ways to draw the circuits to optimise for space
<emOne>
Or am I misunderstanding it?
<buzzmarshall>
used to be a good site that was all about the artwork thats usually fabed on to the chips or wafer
<buzzmarshall>
ye thats part of it
<buzzmarshall>
as well they contain all the information that controls the manufacturing process that creates the actual chip
<buzzmarshall>
and being most of its around gate structure and stuff the chip is built up in a series of layers
<emOne>
Wouldn't it be enough to have the code for an FPGA to be able to manufacture a chip?
<buzzmarshall>
eventually you end up with the complete chip as a wafer which then will be put into some type of encapsulated holder thats to some approved standard
<buzzmarshall>
prior to Socs everything was pretty much discrete circuits requiring tons of parts
<emOne>
And with socs?
<buzzmarshall>
since Socs became the norm alot of what goes into makeing up a system now is sitting on the same wafer as the core
<buzzmarshall>
things like periferals and other chipsets
pyrodex has quit [Quit: What up my glip glops!]
<buzzmarshall>
say back in the days of the 383 or 486 things like the math copro was a separate chip on the motherboard
<buzzmarshall>
nowadays its hardware functionaltiy has been absorbed into the main cpu at fab time
<buzzmarshall>
soc is kinda like that in simplistic terms
<emOne>
So that's pretty good right?
<buzzmarshall>
yes as its allowed things physically to keep getting smaller and faster
<emOne>
All the old arcade cabinets have a seperate chip for everything
<emOne>
Sound
<emOne>
Graphics
<buzzmarshall>
less buss length means lower resistance hence faster speeds
<emOne>
Maths
<emOne>
Etc
<buzzmarshall>
ya thats the idea
<emOne>
But the nice thing about that approach is that they're very reliable
<buzzmarshall>
essentially the idea of the Soc is like replacing the whole motherboard in a normal computer
<emOne>
Limited yes.. But also very reliable
<buzzmarshall>
yes
pyrodex has joined #libreelec
<buzzmarshall>
instead of a regular computer thats designed for a unknown amount of purposes
<buzzmarshall>
most soc's are designed for something much more specific
<buzzmarshall>
keeps the cost down while making things much more reliable
<emOne>
It is a shame that they're a Blackbox
<buzzmarshall>
in the older days alot of the things a soc can do were done thru things like programming a propriatary chip like a cpld or a fpga
<emOne>
I heard the panfrost people managed to get functionality out of the amlogic socs that are undocumented and not even the blobs have that functionality
<buzzmarshall>
its just from a development point the soc is more capable and flexible which is why they are much more prevalent in todays tech
<emOne>
I don't know if you ever coded for ios or mac
<buzzmarshall>
that may be true to some extent depending on whats being talked about
<emOne>
But everything is done through API like code
<emOne>
And libraries
<emOne>
If you want video,,, you use an apple library
<buzzmarshall>
thru trial and error one may discover features inside the gpu that amlogic may not be using
<buzzmarshall>
but no one can or will find anything thats not implemented in the mali by arm
<buzzmarshall>
one cant create new logic inside the mali core thats not already there at fab level
<emOne>
Absolutely
<emOne>
But apparently there is code in there that isn't being used by blobs
<emOne>
It is there. It is just unused
<buzzmarshall>
the mali as an example is really nothing more then a multi-core mcu setup to handle hardware acceleration of known gpu protocols at its time of creating
<emOne>
Perhaps for different licensing tiers?
<buzzmarshall>
its really just a bunch of logic blocks at a hardware level Arm created in its software
<buzzmarshall>
they then licence that core to whoever wants to implement it on their Soc
<buzzmarshall>
as an example
<emOne>
Makes sense
<buzzmarshall>
Amlogic could have decided to use Arms normal mcu and a different gpu
<buzzmarshall>
companies like Amlogic and Rockchip are really just design houses
<emOne>
Like nvidia did for their nvidia shields
<buzzmarshall>
the design and layout the soc as they want and then contract out to a fab house for actual manufacturing
<emOne>
And the cores or code blocks are licensed from arm
<emOne>
So don't they have full access to the core source code?
<buzzmarshall>
the overlap and coverage between core suppliers like Arm and the design house tend to overlap in some areas as the support packages are all different levels of revenue
<emOne>
What does it mean when they say that apple has a special arm license?
<buzzmarshall>
most of Arms cpus are open source and all the published support materials are easy enough to find
<emOne>
So couldn't people just design their own arm cpus?
<buzzmarshall>
its just the GPU area thats become the closed area as theres really only a few companies in that area and they all will fight to protect that
<buzzmarshall>
sure...theres no reason one couldn't take a arm core and only partially use it
<buzzmarshall>
Arm will licence it to anyone wanting use it and you can use it in the manner you want
<emOne>
But they would be missing a leg
<emOne>
:)
<buzzmarshall>
thats why it becaome so popular so fast in the embedded industry
<buzzmarshall>
so they make their licence fees there
<emOne>
Ahh OK ok
<emOne>
So it is still mostly closed source
<emOne>
Ohj
<emOne>
It is open source but the licensing fees have to be paid?
<buzzmarshall>
and then in this case they make another money grap because these soc makers decided to also use something out of Arms catalog for a gpu
<buzzmarshall>
so unless someone buys the DDK or licences the DDK for the Mali they will always have to go back to Arm to have a new blob created everytime they try and update the os on that device
<emOne>
Mali adreno and snapdragon are the biggest sou brands
<buzzmarshall>
thats why in some cases even at a Android level you will see older devices that cant easily be updated to the newest versions of Android on that older hardware
<buzzmarshall>
boxes like the S812 which is like prior to the old Android 5
<emOne>
I always wondered why that was the case with android phones?
<emOne>
! *
<buzzmarshall>
its not that one can't figure how to hack the newer Android onto those devices
<buzzmarshall>
its that the blobs for the new Android wont work on that hardware
<buzzmarshall>
not without creating a non-canned version of Android specicially for that device which costs Amlogic money
<emOne>
Insanity
<buzzmarshall>
there may be other issues but the gpu is the main thing
<buzzmarshall>
Arm is one of those companies setup to make its money thru licencing and pretty much all of its revenue streams work that way
<buzzmarshall>
googles worried about loosing some of its ability to collect data on its users as it slower sees people using its android os wanting to migrate to linux
<buzzmarshall>
googles all about collecting data as thats where its wealth and power comes from
<buzzmarshall>
so its in its own best interest to be part of the development scene to see these issues solved
<emOne>
Hey Alexa
<buzzmarshall>
i am sure its thru some funding and sponsorship thru them that is allowing some of the open source projects to carry on as long as they have
<emOne>
Are you listening Alexa? O_O
<buzzmarshall>
lol
<buzzmarshall>
sbc's are not like the typcial andriod box that was tied to Android so google automatically inherited all the data collection
<buzzmarshall>
sbc's are being created to run on a variety of devices
<buzzmarshall>
as well as a lot of android box users are migrating to things like LE
<buzzmarshall>
if that continues to happen google keeps loosing some of its tracking footprint
<emOne>
Well if people migrate to something like LE Google loses All its tracking abities
<emOne>
At least the ones built into the is
<emOne>
OS
<buzzmarshall>
google didnt aquire Android and let it be free without an adjenda
<buzzmarshall>
again tho it demonstrates the greed on Amlogics part
<buzzmarshall>
they are the ones that should properly support this on the devices they make
<buzzmarshall>
and even Google see's the advantage in doing so
<emOne>
Mhh now I understand
<emOne>
But it isn't only the gpu manufacturers now
<buzzmarshall>
i seriously doubt companies like Arm will change their business model to help the linux people and to be honest the issues are not of their making
<emOne>
Take Mediatek and their WiFi chips
<buzzmarshall>
its the design houses like Amlogic that are the issie
<emOne>
They also don't provide source code
<emOne>
Isn't that crazy???!!!
<buzzmarshall>
it would be like GM making a car that requires a special gas that only they can provide
<buzzmarshall>
if they did that how long would they last in the market
<buzzmarshall>
lol
<buzzmarshall>
not very long
<buzzmarshall>
but here in the media box market companies like Amlogic will continue to last as long as the end users keep buying their devices
<emOne>
It suxks
<buzzmarshall>
further proof of their greed can be seen simply by looking at the new device development cycle... as if Amlogic even cared remotely they would slow the cycle down and let the open source guys catchup a bit with the older devices they sell and have them better supported before moving onto new device
<buzzmarshall>
lol
<buzzmarshall>
thats not whats going on tho
<emOne>
It they would just open source the drivers
<emOne>
Or they would *
<buzzmarshall>
devices only a year or so old are falling by the wayside as people rush out and by the next newest device and then get pissed off as they find out things are still not properly supported
<emOne>
Heh yeaa
<emOne>
You would naturally think that a newer device is better supported
<buzzmarshall>
i have even had a coupld of conversations with a couple of techs that work at one of the bigger manufacturing plants in asia
<buzzmarshall>
even they say the same thing
<buzzmarshall>
which is why alot of those plants really don't waste much money or resources in any type of software updates for the boxes once they hit the open market
<buzzmarshall>
the cycle is now strickly develop, release and move on to the next device
<buzzmarshall>
and they don't have much control as they buy the SoCs from places like Amlogic and can only buy what Amlogic wants to push at that time
<emOne>
Are you guys all astronauts???
<emOne>
Buzz aldrin Marshall
<emOne>
Narmstrong Neil Armstrong
<buzzmarshall>
awhile back i tried to lay my hands on a pile of older S812 and S912 from the plant i buy from
RedSoxFan07 has quit [Quit: RedSoxFan07]
<emOne>
Mhm
<buzzmarshall>
the old S812 stock was basically disposed of and the S912 is heading that way as well
RedSoxFan07 has joined #libreelec
<buzzmarshall>
between the cost of floor space and being a dead device i was told the only value was in recylcing clawback
<emOne>
:(
<buzzmarshall>
so thats the cycle were currently in...which pretty much anyone in the area of trying create solutions in the position that in most cases by the time they figure and fix what they are trying to fix that device is almost dead and obsolete
<buzzmarshall>
haha
<emOne>
Well nothing needs to be fixed
<emOne>
They're just all using old blobs
<emOne>
Because of the licensing structure
<buzzmarshall>
sure it does... thats why theres nothting but old software or no linux support in some areas
<emOne>
It is madness tbh
<emOne>
Or you can run Linux on an old kernel which has a lot of missing features
<buzzmarshall>
another thing to look at is this
<buzzmarshall>
i understand things like licencing and nda's
<buzzmarshall>
yet companies like HK leak out partially materials on stuff thats clearly nd'd with no repursions
<emOne>
It is madness though because it is like an economic game of chicken
<emOne>
The first to blink loses
<buzzmarshall>
HK, Beelink, Weson and others have clearly leaked materials
<emOne>
But by doing that they're all shooting themselves in the foot
<emOne>
Because no one is blinking
<buzzmarshall>
one would think
<buzzmarshall>
yet there not
<buzzmarshall>
to me that says one thing very clearly
<emOne>
They're all going to go out of business?
<buzzmarshall>
and thats is that even at a Android level some of the makers are not getting the support they want from Amlogic and are willing risk the penalties of leaked info in a effort to garner help fronm the public
<buzzmarshall>
alot of devices have always issues even with the canned version of Android being given to them
<emOne>
I am not surprised that they intentionally leak info
<buzzmarshall>
i am sure if you or i were to leak soemthing like the register manual for the S922 i would have someone from Amlogic on my doorstep within hours
<buzzmarshall>
lol
<emOne>
Hehe yea
<emOne>
I would hide in the bushes heh
<buzzmarshall>
but rather then help their downstream makers they will turn a blind eye to them leaking materials clearly watermarked to that maker
<buzzmarshall>
me too
<buzzmarshall>
its all about money and money out and if its gonna cost them more money to stop something then what it would to fix something properly thats what all of this is about
<emOne>
Ehh we need more people reversing their blobs
<emOne>
Not our blobs
<emOne>
Their blobs
<emOne>
Pick their brains a bit just for sport
<emOne>
For the lulz
<buzzmarshall>
anyways thats enough of my rant as i better stop as this aint the place for that
<buzzmarshall>
so whats new with you
<emOne>
Heh yes
<emOne>
Nothing much I have been trying out different kernels
<emOne>
And i have decided that it is best to run a mainline kernel
<emOne>
I have always been for freedom of code
<buzzmarshall>
cool... i had seen you posted over on LE
<emOne>
Yes
<emOne>
Also on armbian
<buzzmarshall>
still messin with the x3
<emOne>
I had some issues with both operating systems
<emOne>
But the issues are identical
<emOne>
I am yes
<emOne>
The mainline kernel behaves strangely with my older TV
<buzzmarshall>
ya i seen your post over in the other channel
<buzzmarshall>
k... ya theyre getting a good collection of sources i see
<emOne>
Apparently it doesn't compile
<emOne>
I have a feeling that the source code was not meant to be public
<emOne>
It compiles on 4.9
<emOne>
Perhaps chewwy tried to compile the wrong source code
<emOne>
Because there is another driver that the 96boards poplar uses
<emOne>
It is the same Chip
<emOne>
But it isn't connected through sdio
<emOne>
So the drivers are not compatible
<emOne>
Perhaps he tried to compile that code
<buzzmarshall>
hm... gettin old and memory sucks but i kinda remember that being part of the new set of drivers which doesn't much in the public yet
<emOne>
I will figure it out
<buzzmarshall>
i member looking at bunch of logs with a couple of key devleopers of theres and one saying soemthing about that model being part of something thats a lot less in the public with firwmare
<emOne>
Yes there was that too
<buzzmarshall>
something about ralink and it being migrated
<emOne>
I think it was connected to some openWRT devs
<emOne>
But the good news is that the coreelec guys did include the code
<buzzmarshall>
hm... i thnk i came across that chipset as well when i hacked open the bootloader for the firetv 4k
<emOne>
And my WiFi does work in CE
<emOne>
Yes
<emOne>
I think it is in one of amazons sticks
<emOne>
And yes I remember you saying you were ripping the stick apart
<buzzmarshall>
yes i think thats where i came across it
<emOne>
I don't have a compiler environment set up
<buzzmarshall>
i did kinda a proof of concecpt thing for someone and the amazon box with that stupid MediaTek processor
<emOne>
So I don't know if it will compile with a mainline kernel
<emOne>
Did it work out?
<buzzmarshall>
maybe take alook at the ce sources and its wifi sources and compare to the le and see whats missing
hijacker has quit [Remote host closed the connection]
<buzzmarshall>
seems to me i remember someone saying somthing to me about renaming something and using something from one of the other devices in that product line and got it to work
<emOne>
This is missing
hijacker has joined #libreelec
<emOne>
There is a post by chewitt on libreelec
<emOne>
He said it wasn't compiling
<buzzmarshall>
so what happens if you try and build LE and pull khadas source?
<emOne>
I haven't tried
<emOne>
But chewitt has and he said in the post that it doesn't compile with the mainline kernel
<emOne>
Perhaps he tried different code?
<emOne>
Wait. Let me try to find the post
<buzzmarshall>
assuming he tried with the same sources then one needs to look abit and see why its not compling
<buzzmarshall>
maybe its just a differnce in some support file that needs to be corrected to compile under the newer kernel
<buzzmarshall>
hard to tell without trying i quess
<buzzmarshall>
that links funny... thats just after the time i said what did over on FT after he said it couldnt be done.
<emOne>
I can't find the post
<buzzmarshall>
lol... ive not been back to FT since to ever see anymore
<emOne>
Ft?
<emOne>
What's FT?
<buzzmarshall>
but if that lets CE complile and give you working wifi it should be able to be hobbled together into LE as well
<buzzmarshall>
FreakTab
<emOne>
Ahh OK
<emOne>
Hmm I can't remember where he posted
<buzzmarshall>
as for CE ive not been back there since numbnuts and i got into that fight over a year ago
<emOne>
"Linux 5.7 has support for MT7668 Bluetooth, but not WiFi, and the Linux 4.9 (Android) driver that can be found in a few places does not compile on recent kernels. I suck at forward porting but might have a look into it as there are a few S905X2/X3 devices with this chip. The firmware was upstreamed to the kernel back in 2018, but no drivers yet."
<emOne>
buzzmarshall: do you happen to have a LE compiler environement set up?
<buzzmarshall>
ya that seems to ring a bell as i remember thinking the same as originally chewy had said the support was in 5.7 but i kinda though something was missing
<buzzmarshall>
which put me on the trail of lookinng into some of the MediaTek logs where i had come across the mention of the shifts in their product line
<emOne>
I can only try to compile it on Monday as my current Internet connection has the speed of a snail
<buzzmarshall>
something bout moving a bunch of chipsets into a single source and less discrete sources
<buzzmarshall>
hm... later this weekend i have to recompile some sources and plan on a LE master with some changes for the S812 and 18.8
<buzzmarshall>
i will throw in those sources just to see what and where the failure is
<emOne>
Awesome!
<emOne>
How much data does a typical LE compilation use?
<emOne>
About 35gb?
<buzzmarshall>
ive got some software running trying to do a board layout and nest for a board i am trying to build
<buzzmarshall>
when its done i was planning on doin some LE complile time
<emOne>
Awesome!! :)
<emOne>
Who knows maybe it compiles just fine and he was using the wrong source code
<buzzmarshall>
i build mine on a machine ive got a sdd on with 32gig or ram and i just set the caches size to 10g
<emOne>
I know that 96boards also use source code to this chip... But it is the wrong code
<buzzmarshall>
takes me bout 3-1/2 hours give or take
<emOne>
Woah nice
<buzzmarshall>
still tho just a old i5
<emOne>
I was actually considering compiling on the s905x3 box
<buzzmarshall>
that would be interesting
<emOne>
Some people said it is faster to compile on an arm cpu
<buzzmarshall>
no idea of how long that would take
<buzzmarshall>
native compiler is usually faster
<emOne>
Well, you're compiling natively when compiling on an arm cpu
<emOne>
Yea
<emOne>
But again those arm cpus are weaker than desktop cpus
<buzzmarshall>
thats soemthing i never tried
<emOne>
But my main machine is an older laptop
lolek has joined #libreelec
<buzzmarshall>
recently i tried compiling a debian system for a beaglebone black i got here
<emOne>
So for me it would make sense to use the TV box itself to compile
<buzzmarshall>
i wont make that mistake again
<buzzmarshall>
lol
<emOne>
Hehe
<buzzmarshall>
sometime when i have more time to kill i want to figure out how to create a jenkins setup
<emOne>
What's that?
<buzzmarshall>
i got a couple spare rack boxes here with 32gig and would like to use them to create my own build machines
<emOne>
What's a Jenkins?
<buzzmarshall>
to be honest other then knowing a lot of stuff online now its being built on it i am still trying to learn more
<buzzmarshall>
some builds when you go to get them are being built the way you want and get built automatically
<emOne>
Oh ok
<buzzmarshall>
i think its just more of a automated way of handling the same build but for a bucnh of different devices
<buzzmarshall>
they call it a jenkins server
<emOne>
That is cool
<buzzmarshall>
i came across while looking into getting into Yocto builds
<buzzmarshall>
i had started a Yockto project to migrate my own os to its build system
<emOne>
I actually once compiled a Linux OS on a dedicated server with a superfast internet connection
<emOne>
Even that took forever
<emOne>
On an i7
<buzzmarshall>
for awhile i was looking at yockto while following Neil A's stuff as i seen he had a project using it
<emOne>
I think it was android aosp actually
<buzzmarshall>
its a neat development setup
<buzzmarshall>
really modular
<emOne>
Cool I will check it out
<buzzmarshall>
its interesting
<buzzmarshall>
some of Neils stuff i think from the panfrost thing was using it
<emOne>
I have used buildroot in the past for the raspberry pi
<buzzmarshall>
anyways it was seein him use it on whatever it was i was looking at the time
<buzzmarshall>
its like buildroot but more capable
<buzzmarshall>
buildroots good with the linux kernel and uboot
<emOne>
Yes
<buzzmarshall>
yocto is kinda just a bit above that and i thnk you can use buildroot inside a yockto project
<emOne>
It was easy enough to use for the raspberry pi
<emOne>
Cool I will check out yocto
<emOne>
Thanks for the suggestion
<emOne>
It is all about having a good build environment
<emOne>
I think that is the biggest hurdle when compiling a whole OS
<buzzmarshall>
another one that i seen using both of those quite a bit was following all the Bootlin youtube vids
<buzzmarshall>
most of that stuff is all about embedded linux and theres a lot of good info in regards to the media/graphix stuff in their videos
<buzzmarshall>
thomas petazzoni talks about a lot of that stuff
<buzzmarshall>
i was following that while researching what needed to be done to create the h265 code that needed to be put into the v4l2 and ffmpeg stuff
<buzzmarshall>
seems they really like buildroot and yocto
<buzzmarshall>
if you ever need to or want to understand things like stateful or stateless in the encode/decode subjects
<buzzmarshall>
thats a great place to go and learn
<emOne>
I have no idea about stateful and stateless
<emOne>
But I gather it is quite important for HEVC
<buzzmarshall>
basically its part of how the encode/decode codecs work when it comes to things like h264 or h265 and the rest of that stuff goes
<emOne>
I gather that h265 already works in private circles
<buzzmarshall>
it has to do with how the packets(data) get handled as they come in from the stream and move thru the pipeline as it gets processed for display output
<buzzmarshall>
yes
<buzzmarshall>
at least in the stateful mode
<emOne>
Which is what the raspberry pi uses?
<buzzmarshall>
statless i have not checked yet tho i do have a rpi4
<emOne>
Is stateless used by the rpi4?
<buzzmarshall>
rpr uses statless or at least that was the direction theyre coders where going the last time i checked
<buzzmarshall>
ive not really messed much with the raspberries yet
<buzzmarshall>
been busy with something else
<emOne>
Yea
<buzzmarshall>
last time i actually checked i was under the impression there were some other example of stateles on diffent platform that was trying to be migrated to the rpi
<emOne>
So what's better for h265?
<emOne>
Stateless or stateful?
<buzzmarshall>
but from reseach the VideoCore gpu used stateless so to try and emulate it in open source would make me think thats the way to go
<buzzmarshall>
to be honest i am not sure but would think it would depend on a few differnt factors
gouchi has quit [Remote host closed the connection]
<buzzmarshall>
its kinda a rob peter to pay paul thing
<emOne>
Yea
<emOne>
Video decoding must be a very specific topic
<buzzmarshall>
basically the differences in the 2 stalks are where pieces of the incoming packets are being retained in memory for use
<emOne>
It is a whole topic by itself
<buzzmarshall>
stateful holds a lot of that info as it goes thru the pipe
<buzzmarshall>
where as stateles strips abunch out earlier and changes how the decode moves thru the setup
<emOne>
Got it
<buzzmarshall>
i wish i was deeper into the graphix things as its interesting to look at
<emOne>
One can not know everything
<emOne>
But yes it is fascinating
<emOne>
I spoke to a kodi dev the other day
<buzzmarshall>
the other issue i think thats still going with kodi and things like v4l2 and ffmpeg is the caching or buffering when trying to jump ahean or backwards
<emOne>
With h265?
<emOne>
Or any codec?
<buzzmarshall>
but i think once they figure out stateful processing of the h265 that will autocorrect itself
<buzzmarshall>
as one thing is kinda connected to the other
<emOne>
But you just said that videocore is using stateless
<buzzmarshall>
just the h265 as far as i am aware
<buzzmarshall>
yes
<emOne>
Also if they already have some code that works
<buzzmarshall>
i think because allwinner is similar theres some common stuff that the dev's are hoping will work on the rsp's
<emOne>
Why don't they release it :)
<buzzmarshall>
to be honest i am not sure actually how far they have got as i havent really played in that sandbox yet
<buzzmarshall>
and as far as the rpi's go i actually only bought one to take alook at moving some cnc setup off the atmel platform to something faster for this machine i am building
<buzzmarshall>
so once i realized that the rpi was crappy for what i wanted to do its been sittin in the box on the shelf since
<emOne>
A raspberry pi is not fast enough for a cnc machine?
<buzzmarshall>
so i havent even tried installing le or anthing else
<emOne>
Yea
<buzzmarshall>
ya its fast enough but with the propriatary crap and trying to get a decent assembly level ide going its not worth the headache
RedSoxFan07 has quit [Quit: RedSoxFan07]
<emOne>
They do have a lot of propriatry crap
<buzzmarshall>
ive moved back to TI's sitara platform on the beaglebone were nothing is propriatary
<emOne>
But at the same time the community is quite large
<emOne>
And the devs do actively develop for the pi
<buzzmarshall>
rpi's issue is broadcom
<buzzmarshall>
there even worse then amlogic
<buzzmarshall>
lol
<emOne>
Hehh yes I know
<emOne>
They even sell add on licenses for video Codecs
<emOne>
Which is quite surreal if you ask me
andy-burns has quit [Ping timeout: 256 seconds]
<buzzmarshall>
i only know what i know because for years i hacked broadcom junk as it was really propular in the sat industry
<buzzmarshall>
its either them or st
<buzzmarshall>
give me st any day
<emOne>
Who is st?
<buzzmarshall>
over the years i collected a lot of materials on broadcom but overall i am not a big fan
<emOne>
My sat box uses a broadcom chip actually
<buzzmarshall>
st micro electronics
<emOne>
But it isn't an arm cpu
<emOne>
It is a mipsel
<buzzmarshall>
the stm32 is a popular platform of theres
<buzzmarshall>
yes and yes
<emOne>
I think I have seen the logo
<emOne>
Also MIPS?
<emOne>
I don't know why but to me MIPS seemed like junk
<emOne>
OK I googled it. Stm32 is arm
<buzzmarshall>
st is also the makers of the ST19 secure platform which some of the CAS's use
<buzzmarshall>
there were some generations of mips units as well in the way back days
<buzzmarshall>
some of the earlier sat tuners here in NA were mips based for awhile
<buzzmarshall>
for general messing around and playing the STM32 isn't a bad setup and theyve got tons of cheap dev boards if your into electronics stuff
<buzzmarshall>
not to the level of the type of sbc's where seeing here for media stuff
<emOne>
I am good with my s905x3 shenanigans for now
<buzzmarshall>
but for general projects in a ton of areas otherwise there pretty good
<emOne>
I believe you
<buzzmarshall>
and being arm theres a certain amount of skill set carry forwards as you learn
<buzzmarshall>
believe me i here you
<emOne>
My s905x3 has given me enough headaches as it is
<buzzmarshall>
i spent so much time over the years jumping around its stupid
<emOne>
I didn't expect arm to be more complicated than x86 tbh
<buzzmarshall>
but i tend to go where i get interested in something as i have a short attention span
<emOne>
That's a good thing tbh
<buzzmarshall>
more of a jack of all trades master of none
<buzzmarshall>
lol
<emOne>
I just want to first finish the s905x3 chapter first though
<emOne>
Hehe
<emOne>
Well
<emOne>
Master of decapping
<emOne>
And atmel
<emOne>
I would say
<emOne>
And smart cards
<emOne>
There are not too many people who can do that
<buzzmarshall>
being a assembler type i find the move from one to the other not to bad as assembly is basically assembly without worring about the abstraction of the high level languages
<buzzmarshall>
its just slow as working in assembly is slow
<emOne>
That is pretty cool
<emOne>
So you can modify any code basically?
<buzzmarshall>
but extremely fast and for timing related things the best
<emOne>
No matter if it is c, c++ or python
<emOne>
Because all code eventually has to be translated to machine language
<buzzmarshall>
basically if you can lay your hands on the instruction set for the mcu or cpu and can learn to dissassembe binary dumps your at least in the ball game
<emOne>
So you can basically modify the raw low level code without having to touch the high level?
<emOne>
Yea
<buzzmarshall>
the hardest part is probably learning to disassemble a binary file
<emOne>
Oh
<buzzmarshall>
thank god for apps like IDA PRO
<emOne>
Yea
<buzzmarshall>
taking a hex dump can be alot of work to take apart and try and reproduce or create buildable sources
<buzzmarshall>
but linux or bsd at least puts the tool part of that within reach
<buzzmarshall>
windows is garbage for that
<buzzmarshall>
but does give you a platform to run idapro on
<emOne>
Hex dumps at least let you modify some text strings :)
<emOne>
Is there no tool thy is better than Ida Pro these days?
<buzzmarshall>
ida pro is the best you will come across as its sdk will let you build a software model of the mcu or cpu you want to work on
<emOne>
Ida Pro is super complicated too
<buzzmarshall>
you build the model based on whatever info you can glean on the processor
<buzzmarshall>
things like its instruction set and stuff
<emOne>
Are there no pre cooked models around for the cpu?
<buzzmarshall>
then you can take the binary or hex dumps and open them in ida using the modelled processor you make
<buzzmarshall>
and start to take apart the code to see it at a assembly level
<buzzmarshall>
some cpus are commonly found
<buzzmarshall>
in the case of the S812 and the S912 i created the core model
<buzzmarshall>
using boundary scan dumps and other peices of code along with the register docs peiced together a setup that lets you manually step tho the code as you dissassemble it
<emOne>
And that's one of the reasons why I am
<buzzmarshall>
as well i created empty mali blocks and started populating things under observation
<emOne>
Why arm cpus are strange
<emOne>
You see
<emOne>
With x86
<buzzmarshall>
i find the most confusing things about arm are the variety of cores
<buzzmarshall>
theres so many different ones
<emOne>
Yes
<emOne>
Yes!
<emOne>
Is there no standardisation?
<emOne>
I get it why it is like that
<buzzmarshall>
i thnk there is within the architecture groups
<emOne>
But surely it isn't good for the long term plan
<buzzmarshall>
but its overwhelming how many there are
<buzzmarshall>
thankfully most things i play with seem to fall withing similar architectures and product lines
<emOne>
All I am going to say is arm macbooks
<emOne>
Let's see what happens with the cpu inside of those machines
<emOne>
Perhaps they will standardise the cores that are being used in an arm cpu
<emOne>
Geez the whole arm world is crazy
<buzzmarshall>
i like risc based architectures so i dont mind arm but your right its one hell of a learning curve
<emOne>
It starts with the bootloader
<emOne>
After that you have device trees
<emOne>
Now all of a sudden you have these gpus
<emOne>
With propriatry drivers
<emOne>
And after that you have the licensing game of chicken that all these design houses are playing
<buzzmarshall>
true but the nice part is in the end you end up with a nice modular setup where things tend to play nicer together then the way it has been over the years
<buzzmarshall>
u-boot is finally arrived at the point where some of us have been for awhile
<buzzmarshall>
actually i should qualify that as its not really u-boot that was behind as it hasnt been
<buzzmarshall>
but the way most use it
<buzzmarshall>
its capable of doing even more then what most are currently seeing if one starts looking at adding things into it
<buzzmarshall>
for example
<emOne>
I still don't understand why s905x S905X2 s922 and s905x3 all use different uboot build
<emOne>
U boot
<emOne>
Universal Boot
<buzzmarshall>
over time things like LE have become so deeply entrenched in its reliance on systemd for control and start up
<buzzmarshall>
its created a problem being able to easily pop out of kodi and to a terminal window without a whole pile of work
<emOne>
Mhm
<buzzmarshall>
almost all of these distros have the same issue
<buzzmarshall>
i get why as it was all about improving startup time and reliablity but in doing so has locked out certain things or at the very least made trying to do so a whole lot more work
<buzzmarshall>
being old school bsd ive seen both sides of the fence on the start up think debate
<emOne>
why would systemd not allow for exiting kodi and into a terminal window?
<emOne>
I mean.
<emOne>
They're not related
<buzzmarshall>
sure they are
<emOne>
Elaborate
<buzzmarshall>
systemd is what le uses to pull itself up
<emOne>
Sure
<buzzmarshall>
over time more and more of the various systems have been migrated into being controlled by it
<buzzmarshall>
even things like permision levels
<buzzmarshall>
basically the system is setup to boot and run one app
<buzzmarshall>
kodi
<buzzmarshall>
pretty much all the mechansims that would let you switch windows on the fly and go down to command line at a terminal
<buzzmarshall>
don't really work
<emOne>
A shell and terminal could be added to systemd
<buzzmarshall>
take alook at busybox's sources
<emOne>
It doesn't work because LE outputs directly to the framebuffer
<emOne>
And has no windowing system
<emOne>
You could still open up an ssh connection to LE
<buzzmarshall>
not saying that it can't but sofar its not and whenever i come across a post with people asking about droping to a terminal window i see people saying it cant be done
<buzzmarshall>
hold on im not talking about ssh
<emOne>
Ssh?
<emOne>
Ok
<buzzmarshall>
as thats usually the answer given out
<buzzmarshall>
i don't mind it and use it all the time
<buzzmarshall>
but sometimes i might want to just go to a shell for whatever reason without having to come in across a serial link
<emOne>
Sure
<buzzmarshall>
to take the existing setup and make that work is basically a night mare
<emOne>
It is true yes
<emOne>
That is why I am debugging in armbian
<emOne>
Even though the boot time is so horrible
<buzzmarshall>
a long time again before the build system evovled to where it currently is that was much easier to do
<buzzmarshall>
the differences are over time to make the build better suited to its purpose system has become a bigger part
<buzzmarshall>
thus making things much more work
<buzzmarshall>
don't get me wrong as i am not saying its wrong
<buzzmarshall>
only trying to make a point about how we got here talking about uboot and being able to use it to more extent
<buzzmarshall>
i am really happy to see it becoming much more standardized in these types of projects
<buzzmarshall>
the way they have migrated and moved things like the dtb setup is great
<emOne>
Geez, all I want is a file I can drop my sd and not have to worry about the uboot
<emOne>
Drop on
<buzzmarshall>
uboot built into the distro
<emOne>
How did it work regarding device trees before dtb?
<emOne>
Was it even more of a headache?
<buzzmarshall>
another issue with a lot of devices is with uboot and its parts not working right because of things like differnt memmory chips used in forming the memory arrays
<emOne>
Hehh
<emOne>
Yes I remember we talked about that
<buzzmarshall>
usually the propriatary part or vendor portion of the bootloader contains the timing values
<buzzmarshall>
and without them the device hangs
<buzzmarshall>
uboots framework allows for some pretty creative stuff
<buzzmarshall>
before the idea of the dtb everything was hard coded
<buzzmarshall>
so either the vendor provided the info in some form and you hardcoded it into the compile or had to figure it out on your own
<buzzmarshall>
and over time even the same vendor would change things leaving a big mess where everything was discrete
<buzzmarshall>
made building and loading the kernel with drivers a real pain in the arse
<buzzmarshall>
over the years the whole idea of drivers has evolved to where it is now which is so much nicer and once everything is done will make adding and maintaing stuff much easy
gouchi has joined #libreelec
gouchi has quit [Client Quit]
<emOne>
Hardcoded into the kernel?
<buzzmarshall>
the dtb is a key part of that which will at some point reduce things down to the vendor suppling a dtb for the device and putting the rest of the maintainance into the hands of the ones maintaining the maintream
<buzzmarshall>
ya
<buzzmarshall>
using ce and le as an example
<buzzmarshall>
we already can see the direction le and the rest of linux has gone and will continue to go
<buzzmarshall>
and at some point keeping the software running and up to date will be easier
<emOne>
CE and LE devs should unite
<buzzmarshall>
ce on the other hand has to still depend on its main piece of code running on a kernel thats alteredl by say Amlogic
<emOne>
v Peter who was here earlier is often in ce
<emOne>
The devs should all work on the mainline kernel
<emOne>
And I also mean the people over at ce
<buzzmarshall>
and because Amlogic's linux coders didnt really give a crap about anything other then their own devices wrote their board support stuff outside of the normal linux tree
Fenster` has joined #libreelec
<emOne>
Because they do have very talented individuals therev
<buzzmarshall>
yes i agree there is a bunch of good guys on both sides of the fence as they seem to be genuinely interested in seeing things improve without being tied to one or the other
<emOne>
But one side is evil :(
<emOne>
They need to join the light side of the force
<buzzmarshall>
and even tho the differences in phylosphys they don't get stuck there
<emOne>
Yea
<buzzmarshall>
but to a few others its like a war between one or the other which is kinda what i was talking about earilier with the all the social stuff
<emOne>
Hehe yes
<buzzmarshall>
its to bad because none of it is worth that kinda crap and it makes it hard for anyone just looking for a simple solution
Fenster has quit [Ping timeout: 240 seconds]
<emOne>
Lol yes I know that
Fenster` has quit [Ping timeout: 264 seconds]
<emOne>
Ehh hold on
<emOne>
I got to grab a bite to eat
<buzzmarshall>
i even get the whole mine is better then yours mentality to some extent because people take pride in what they do and there are a lot of guys here that put in tons of time for nothing
<buzzmarshall>
no probs
<buzzmarshall>
i will be here anyways while i am building something
<emOne>
I don't think that the people here put in a lot of time for nothing
<emOne>
Ehh I am still here
<buzzmarshall>
lol
<emOne>
It is tempting to go with a 4.9 linuc distro
<emOne>
On ARM
<emOne>
Because there are no crucial bugs or glitches in in the devices
<emOne>
All blobs exist
<emOne>
And firmware and drives
<buzzmarshall>
to be honest i think its great that people have that choice
<emOne>
Yes
<emOne>
But on the other hand
<emOne>
Everyone should be focusing on mainline
<emOne>
Linux is not android
<emOne>
Not at all
<buzzmarshall>
if all you really want is a working system and what revision your on isn't a issue its great to have that option
<emOne>
Android is an app inside of Linux
<emOne>
That is all that android is
<emOne>
An app inside Linux
<emOne>
It is therefore wrong to develop the os around the app
<buzzmarshall>
thats why even tho numbnuts and i don't get along and i don't bother with CE anymore its still great to see one supports things one way while the other is looking further down the road
<emOne>
Yes
<buzzmarshall>
another factor i think tho i maybe wrong about as i am not connected to anyone here is that my impression is that
<buzzmarshall>
LE is alot more tightly coupled to Kodi devs and Kodi is really the driving app behind these distros
<buzzmarshall>
so logically this is the place to be
<emOne>
I have noticed that kodi and LE is a lot tighter
<emOne>
Which I like
<buzzmarshall>
i havent and dont use kodi on anything other then linux and coming here is much better then their social nightmare of a web forum
<buzzmarshall>
lol
<emOne>
Heh yea
<emOne>
Oh I have kodi on ios
<emOne>
I have kodi on macOS
<emOne>
I have kodi on Windows
<buzzmarshall>
so hanging here is much more peaceful in my mind
<emOne>
And now on the s905x3
<emOne>
Yes I will be here more often
<emOne>
Much more often
<buzzmarshall>
i used to have on ios till i stopped years ago
<emOne>
But it also makes me mad
<emOne>
Kodi on ios is only for jailbroken devices afaik
<buzzmarshall>
and out of over a dozen computers running in the house here i have 2 windows machines
<emOne>
Apple doesn't allow kodi in the app store
<buzzmarshall>
one my wife uses on a laptop
<buzzmarshall>
and i keep one windows box for idapro on my live network
<buzzmarshall>
everything else is linux
<emOne>
The first time I used xbmc was on Windows
<emOne>
Actually
<buzzmarshall>
oh i do have a 27" imac still online as well
<emOne>
It was on the original xbox
<buzzmarshall>
yep
<buzzmarshall>
i started back then when frodo 1st released
<buzzmarshall>
it was xbmp
<emOne>
I also had the frodo build
<emOne>
Wait.. Frodo is v12?
<buzzmarshall>
to be honest i dont think anyone in the current kodi line was even around back then
<buzzmarshall>
lol
<buzzmarshall>
before that
<buzzmarshall>
im talking about the coder frodo
<emOne>
Ahh OK
<emOne>
I had a version before it was renamed to xbmc
<buzzmarshall>
he had yamp
<emOne>
Even though I always remember it as xbmc
<buzzmarshall>
the xbmp guy was named duo
<emOne>
Could you get the project Gotham skin for xbmp?
<buzzmarshall>
tho i think his actual nick was something like d703 blab
<emOne>
Or was that only for xbmc?
<buzzmarshall>
i cant remember it all
<emOne>
Ahh yes
<buzzmarshall>
woulda been sometime back around 2002
<buzzmarshall>
him and runtime i think it was
<emOne>
Back to the point of mainline vs 4.9
<buzzmarshall>
then it became xbmc
<emOne>
LE does make me mad
<buzzmarshall>
now its kodi
<emOne>
Yea
<emOne>
OK so back to LE
<buzzmarshall>
why mad at le
<emOne>
Not LE but mainline
<emOne>
Because shit is just broken
<emOne>
And I get mad
<emOne>
And I go back to ce
<emOne>
Until I realise that while stuff in ce works.... It is not the OS that I need
<emOne>
So in ce the os is built around kodi
<emOne>
Which is insane if you think about it
<emOne>
While in LE the os is aiming to be a strong foundation
<emOne>
Where unfortunately a lot of stuff doesn't yet fully work
<emOne>
But you don't go and build a brick house on top of quicksand
<emOne>
Which I feel is 4.9
<emOne>
There is already panfrost in mainline
<emOne>
You can't have that in 4.9
<emOne>
Panfrost even unlocks features that the official blobs dont support
<emOne>
Dunno. I don't like being constrained by the os
<buzzmarshall>
i understand what your saying but look at things kinda like fixing up a old car
<emOne>
Which is what 4.9 is
<buzzmarshall>
how much do you keep sinking into something that eniviably is doommed
<buzzmarshall>
right now CE has a bit of a edge because its running on old tried and tested kernel
<buzzmarshall>
but like a car every month or so it gets another hole or something break
<buzzmarshall>
now i got to spend time trying fix something
<buzzmarshall>
when and where that cycle becomes a waste is whats kinda goin on here
<emOne>
Yes
<buzzmarshall>
Le is like byin the new model but it comes with bugs
<emOne>
Yep
<buzzmarshall>
so in the end its kinda up to the enduser to decide whats more important to him
<buzzmarshall>
theres nothing wrong with running on old stuff in my eyes
<emOne>
Enduser just cares if it is shiny
<buzzmarshall>
but being a forward thinker in most ways i put my value in moving ahead
<buzzmarshall>
in the end tho one thing is for sure
<buzzmarshall>
LE and Kodi are tightly couplled and Matrix and its requirments are on the way
<emOne>
Awesome
<buzzmarshall>
distros like CE are investing their time and efforts in mostly maintaining old stuff
<buzzmarshall>
what happens when matrix is finaly and maybe CE dosn't play nice with it running on old stuff
<buzzmarshall>
now in the middle of all of this i am better then you crap
<buzzmarshall>
they will be raiding LE's github trying to patch their mess while LE is now out front
<buzzmarshall>
haha
<emOne>
For sure they will
<emOne>
Oh. Man
<buzzmarshall>
the best way to avoid most of that is with dudes like peter and some others that kinda are working both sides of the fence
<emOne>
Yea
<buzzmarshall>
thats why peeps need to appreacate people like him
<emOne>
True
<buzzmarshall>
otherwise when and its not a matter of if that happens it will be a real shit show again
<emOne>
Hehh true
<emOne>
Chewitt is a pure LE person
<emOne>
But I haven't seen him around in chat in ages
<buzzmarshall>
seein as i don't go to ce any more i am not really up on the group of guys doing double duty
<buzzmarshall>
i just no its good that there are some
<emOne>
I have popped in a few times
<emOne>
But I haven't seen him around
<buzzmarshall>
other then that once and awhile i talk to Ray and am aware he's kinda back over there which makes me happy
<buzzmarshall>
i think i seen someone say chewy's on holidays or something
<buzzmarshall>
but your right its been awhile since i last seen him
<emOne>
One of the things that turned me away from LE was that I was under the impression that there was no hw acceleration for video
<emOne>
But I tried it for a bit and it actually works well
<emOne>
Apart from HEVC ofc
<emOne>
But that too is coming
<emOne>
Dunno
<emOne>
The whole arm world is a mess tbh
<buzzmarshall>
the linux-meson website is pretty good at giving you a general idea of whats working and not and seems to change as things get fixed
<emOne>
But I do see why people are discouraged by arm
<emOne>
I know it's not the fault of arm
<emOne>
It kind of goes against the whole Linux open source philosophy
<emOne>
Which is just mind boggling
<emOne>
It is a bit like convincing yourself to do something bad and telling yourself that it's alright
<emOne>
I am talking about all the different device vendors
<buzzmarshall>
not that i am particular about Arm but really ya none of the issues are the fault with Arm and in most other ways
<emOne>
You don't just take something like Linux and shit on it and tell yourself it's OK
<buzzmarshall>
Arm has supported linux really well
<buzzmarshall>
its just they happend to produce the gpu cores that the soc designers choose to use
<emOne>
Companies like amlogic and all the different gpu companies haven't
<buzzmarshall>
company's like Amlogic knew how it worked and in the beginning i could even understand why they didn't want to invest in linux
<buzzmarshall>
but now with linux becoming the way it is they should have adjusted their thinking in regards to linux along time ago
<buzzmarshall>
personally with everyone i know
<emOne>
Ubuntu OS was a huge success that made the founder a billionaire
<buzzmarshall>
hardly any one of them run android on any of their devices other then a phone or tablet
<emOne>
Yea
<buzzmarshall>
and even then all they do is bitch about all googles snooping
<Ommand>
plenty of people have android on their shield tv or similar
<buzzmarshall>
i think had the emerging sbc market not started using amlogic crap that maybe then they would have maybe changed somewhat trying to retain the box industry as more and more wanted linux or LE style of setup
<buzzmarshall>
but once the makers of the sbc's committed to using aml it got aml off the hook
<emOne>
Android isn't an os IMHO
<emOne>
Android is an app for Linux
<buzzmarshall>
now there right back to not giving a crap
<buzzmarshall>
to me Android is a touch screen system that was half assed hacked years ago to give it a remote so things like kodi could be put on a cheap box
<buzzmarshall>
its buggy and for what hardware it runs on a real crappy performer
<buzzmarshall>
yet on a tablet or phone its somewhat better
<emOne>
If you want better and more features you need to make the OS more capable
<emOne>
Not the app inside the os
<buzzmarshall>
thats why even the newest box with the newest android the remote is still a real peice of crap