<buzzmarshall>
chewitt thanx for the info and i had totally forgotten about OpenBricks and assumed it was done
<buzzmarshall>
i have my own linux i did years ago and not really into Armbian or the desktop thing right now
<buzzmarshall>
i just kind of liked the layer idea in yocto as it seems like a way for me to move years worth of discrete projects into a common framework and have been making some headway learning and moving stuff into OE/Yocto
<buzzmarshall>
yesterday i managed to build your master and 9.2 branches and once again had to relearn your build as things have changed again
<buzzmarshall>
its nice tho i am still playing so i need to relearn again
<buzzmarshall>
seems like everytime i build your sources the build chain is getting a bit quicker and less hassle
prahal has joined #libreelec
<chewitt>
the LE build-system is one of our "hidden in plain sight" secrets
<chewitt>
it's quite capable and well maintained
<chewitt>
and since the parallel build changes went in, it's pretty efficient
<chewitt>
I'm clean building an Amlogic or RPi image in ~25 mins
<chewitt>
albeit on something with lots of cpu cores
<chewitt>
its one weakness is that the package set we have available is very monotheistic around media use
<chewitt>
so if you want to do some other project or IoT device there's some donkey-work needed to make packages for your apps and dependencies
<chewitt>
but once done .. you end up with a tiny image where you have very precise version control
<chewitt>
I've always wanted more people to fork us and do something different with our codebase application-wise
<chewitt>
but it's never really happened at scale
adhux0x0f0x3f has quit [Remote host closed the connection]
<chewitt>
the main reason to want/encourage it is that diversity in use tends to find new and exciting bugs .. which ultimately improves the codebase
adhux0x0f0x3f has joined #libreelec
hijacker has quit [Quit: Leaving]
<buzzmarshall>
ya i can see your point
<buzzmarshall>
i look at things were all those years ago when you guys started and where things are now and man they sure have come along way
<buzzmarshall>
the only real reason i didn't stop my old antiquated methods was i only ever really build for a small group of devices in this scene so when your old you tend to stick with what you know
<buzzmarshall>
over the years i always built the others as well but found the alterations they made tended to usually give me grief in some way or another
<buzzmarshall>
i build you master yesterday and even tho alot of the screen is new to me it worked very well
<buzzmarshall>
nice job to the guys working on it
<chewitt>
there have been two big evolutionary moves since the start
<chewitt>
the first was sraue/seo collapsing everything into a single package.mk format; originally it was split into 4-5 different files (see how OpenBricks still does it)
<chewitt>
the second was milhouse moving us to parallel build, which massively reduced build times
<chewitt>
now we're chasing marginal gains
<buzzmarshall>
i kinda member the old way and definately remember the intro into parallel builds
<buzzmarshall>
for awhile because i only occasionally do your builds man i hated that at 1st
<buzzmarshall>
now its much better
<chewitt>
the only way to make another large gain is moving the toolchain out i.e. build it in advance
<buzzmarshall>
ya i can see that as i have always used toolchains installed in my local workstations
<chewitt>
we spend lots of time waiting for specific toolchain items to build; nothing else can build until they complete
<buzzmarshall>
but that can be really problematic at times as well
<buzzmarshall>
well at least this last build i went thru i didn't have to start and stop a couple of times as things were building out of order at times
<chewitt>
it's technically not hard to implement, but requires/implies a level of orchestration which will be hard(er) to maintain
<buzzmarshall>
i think you guys now have that nailed down pretty good from what i seen
<chewitt>
and at the end of the day we're just a bunch of people doing things in our spare time as a hobby
<buzzmarshall>
i can relate
<buzzmarshall>
thats why i have over a half dozen workstations downstairs as i got sick of intermixing crap in the tool chains
<buzzmarshall>
i just found it was simpler to use a bunch of machines each setup for what i needed
<buzzmarshall>
but not everyone has the ability to do that
<buzzmarshall>
i got a bit of time coming up inbetween projects and am looking to trying to help fixup a few things and rather then doing it my own old way want to use your sources
<chewitt>
go nuts
<buzzmarshall>
so if i go down that road what do i need to do to keep you guys happy
<chewitt>
reduce, reuse, recycle
<buzzmarshall>
just keep it in one of my githubs as far as sources go and then just release the images?
<chewitt>
it's all GPLv2 so you're welcome/entitled/encouraged to fork and use and do things with the code
<buzzmarshall>
i am still gonna carry on down the yocto road as i have boards i develop for outside the realm of this media stuff but for the sake of conveniance want to stay with your stuff
<chewitt>
if you're going to commercially release something or images; you're technically required to include an offer to provide sources
<chewitt>
which is easiest done by pushing code to somewhere public
<chewitt>
if you find bugs/issues and have a fix .. PRs are always welcome
<buzzmarshall>
ya i can do that on my github and as well as server space online
<buzzmarshall>
with your masterbranch and the 9.2 branch and the Amlogic projects which would be the best for me to look at
<chewitt>
there's a pile of changes in my repo that are needed for SM1 support if you're looking at that
<buzzmarshall>
i can put a Amlogic project back into the 9.2 or carry on with the master which has some but really didnt spend much time comparing how they stack up to each other
<chewitt>
I will get around to sending them upstream at some point .. I just don't have much time at the moment
<buzzmarshall>
k. i did see your repo as well
<buzzmarshall>
usually i was watching balbes repos but hes got more going on then i want to get into
<buzzmarshall>
ya i get the time thing as this is a hobby for me as well
<chewitt>
he also sucks a commits and git ettiquette
<buzzmarshall>
haha... well that will be me as well
<chewitt>
e.g. marges 400+ changes and submits one commit with the message as a date
fraggle_laptop has quit [Remote host closed the connection]
<chewitt>
completely impossible to track change
<buzzmarshall>
crap when i started git didn't exist and spending the time to learn it after the fact was something i never put much time into
<buzzmarshall>
i am getting better tho
<chewitt>
I've attempted to teach him "git rebase" but my Russian isn't good enough for that
<buzzmarshall>
haha
<chewitt>
for someone that doesn't actually speak English at all .. I think he does quite well :)
<buzzmarshall>
i went and pulled a bunch of tuts online and kinda keep going back to them when i come up against something i don't get
<buzzmarshall>
oh for sure
<buzzmarshall>
i member when he started at FT and now he's come along way
<buzzmarshall>
seems like there is good interest in the russian forums but i generally try and stay out as i don't know squat without a translation app running
<chewitt>
Russian users post the same garbage as English users .. and a lot more piracy discussion
<buzzmarshall>
i used to see him a lot over on khadas and now if i didn't know i'd think he was just some euro/eng guy
<chewitt>
I can read things to a moderate level without reaching for Google translate as long as people post in normal language .. I don't get the slang
<buzzmarshall>
ya the piracy stuff kinda moved there and asia a few years ago
<buzzmarshall>
its big over there, still is around NA as well but pretty much now all exclusive invite only
<buzzmarshall>
nsa and 5 eyes are watching pretty much everything here these days
<buzzmarshall>
regarding the LE sources
<chewitt>
NSA and similar don't give two shits about piracy.. not their mission
<chewitt>
you can be concerned about them for other reasons, but not that one
<buzzmarshall>
true but there typical snaring programs gather way to much crap and then everytime some corp wants to squeeze on some particular issue they use that data in alot of cases
<buzzmarshall>
special here in CA
<buzzmarshall>
with the mainstream providers here running in a protected environment things like streaming offshore and protected content is a huge issue
<chewitt>
it's a global issue
<buzzmarshall>
yea thats true
<buzzmarshall>
here in Canada as theres areally only a couple of authorized services tho they are always running to the gov and courts to clamp down
<buzzmarshall>
probably over a 1000 dealers and crap still sitting in the court dockets
<buzzmarshall>
only good thing sofar i see is its kicked the crap outta Adam and his scams with you know what
<buzzmarshall>
i'll leave it nameless
<buzzmarshall>
lol
<buzzmarshall>
with the LE branches is there any particular reason the amlogic projects left out of the 9.2 versus being in the master branch?
<chewitt>
Yup, the 3.14 bsp codebase is a massive festering turd that everyone got fed-up of maintaining
<chewitt>
our focus moved forwards onto mainline things
<chewitt>
so LE 9.2 is deliberately missing Amlogic
<buzzmarshall>
k... thats kinda what i thought
<chewitt>
and master deliberately re-adds it, but only for mainline kernel things
<buzzmarshall>
so if i want to work within the confines of 9.2 i just need to make sure to stay on the 5's
<buzzmarshall>
which is really where i want to go
<buzzmarshall>
so if i recreate some specific amlogic projects in 9.2 i just need to be aware of the upward move then?
<chewitt>
9.2 is a minor evolution of 9.0 which still had support, so will probably work
<chewitt>
master will have one (maybe two) issues
<chewitt>
first is that Kodi no longer supports amcodec at all
<chewitt>
second is that the oldest kernel we're building against is (was) Linux 4.4 for Rockchip .. so stuff that needs 3.14 may or may not build okay
<buzzmarshall>
k... so if i were to drag say the old s912's up to early 5's and make them work that would not be a issue
<buzzmarshall>
i am not really interested in the old crap either
<buzzmarshall>
some of us stopped using amlogics bsp crap along time ago
<chewitt>
master with a 5.2/5.3 kernel and older patches for vdec and audio is quite usable
<chewitt>
right now things are in a lull point
<chewitt>
the upstream api's for stateless/stateful decoding firmed up, which needed rework in the vdec
<chewitt>
this work is still ongoing, and some work to adapt ffmpeg to the revised vdec is still pending
<buzzmarshall>
k... its been awhile since i looked at ffmpeg and wasn't sure things are
<chewitt>
until the ffmpeg work is done, video playback isn't in good shape
<buzzmarshall>
but i have been kinda following the panfrost and lima projects
<chewitt>
panfrost is solid for s912 now; has been for a few months
<chewitt>
the kernel driver is stable and it's passing all the dEQP tests; there are some VIM2's in the mesa ci labs to spot regressions
<chewitt>
master still has 19.2.3? .. bump to HEAD (will be v20) and things are stable/solid
<buzzmarshall>
hows lima doing on some of the older s905s i never really messed much with them as i just went straight into the 912's when the came out
<chewitt>
overall not as polished as panfrost, but more than good enough for Kodi use
<chewitt>
our RK images are now switched from blobs to lima/panfrost and most of the Allwinner images are done too
<chewitt>
soon the only blob using devices will be the newer Amlogic kit
<buzzmarshall>
cool...
<buzzmarshall>
that was going to be my next question in regard to Amlogic
<chewitt>
bifrost support is some way off .. panfrost devs want to get midgard to a more complete state for desktop use before they start trying to RE something even more complicated
<chewitt>
there are still a ton of magic values to figure out for midgard
<chewitt>
but one by one, things get figured out
<buzzmarshall>
RE probably is the quickest in some ways as compared to shooting the dark at some things via trial and error
<chewitt>
it's a truly impressive effort
<buzzmarshall>
but can be a timeconsuming process
<chewitt>
all the more impressive when you learn the lead developer is a 17-year old who finished high-school ~5 months ago
<buzzmarshall>
yes... she's pretty impressive
<buzzmarshall>
good future for her
<buzzmarshall>
i've been following her stuff here and there since she 1st emerged awhile back and at 1st had no idea of her age
<buzzmarshall>
pretty impressive
<buzzmarshall>
they just need some help hardware wise to get a better understanding of how the ip core is running in the hardware logic
<chewitt>
there are some behind the scenes connections into ARM
<buzzmarshall>
short of stripping the SoC down layer by layer the only other way i know of is to make a wedge and stick it between the SoC and board and then use jtag and some diagnositic stuff to watch the nets and see some things
<buzzmarshall>
making that wedge tho is not something for the faint hearted
<buzzmarshall>
haha
<chewitt>
ARM folks can't help directly, but they've intervened to stop people wasting time on the wrong rabbit holes a couple of times
<buzzmarshall>
ya i have ran across a few over the years in my travels as know a few that don't always agree with the way things are but its a job
<buzzmarshall>
personally i get Arms whole business model and the idea behind ip cores but the whole mali crap kinda irks me and a few others in the circles i travel
<buzzmarshall>
its not like they arent making enough with embedded stuff and Arms processor cores
<chewitt>
the open-source group are very supportive of the effort, some of their folks have been quite productive with the kernel driver side
<chewitt>
the mali team are at arm's length [sic] though
<buzzmarshall>
one would think they'd put the mali's in with the rest
<buzzmarshall>
ya... gpu stuff next to secure smart cards are a hugely protective industry
<buzzmarshall>
theres still ongoing litigation with Arm and the Mali's between them and AMD that goes back to some old ATI stuff
<buzzmarshall>
its been going on for years
<buzzmarshall>
its nice to see the other arm guys trying to help
fraggle_laptop has joined #libreelec
<buzzmarshall>
but i seriously doubt any of them would have access to the verilog or vhdl files used to create the logic cores the ip code sits in
<buzzmarshall>
so the only other way is either to passively use jtag and some software to snoop on the interaction between the processors and the gpu hardware
<buzzmarshall>
or to strip the SoC
<buzzmarshall>
the passive way technically is probably within the law as long as nothing can be proven as propriatary in whatever gets released
<buzzmarshall>
stripping the SoC down tho is another thing
<buzzmarshall>
here in NA theres been alot of changes to the law in methods like that
<buzzmarshall>
to be honest im suprised someone in Asia or mabye Russia has not done that
<buzzmarshall>
anyways nice chat and thanx for all the info and i thnk i will play with your master branch then for now till i get started
<chewitt>
core packaging in my branch is in good shape right now
<chewitt>
kernel sources need work
<chewitt>
right now some of the patch-sets that I want to use are overly dependent on drm-next and media-tree branches that simply don't align for dependencies
<buzzmarshall>
k... when i get home i will look into your repos as well
<chewitt>
in theory some of that resolves once the 5.6 merge window completes in ~ 2 weeks time
<buzzmarshall>
me not being a git guro let me ask you this
<buzzmarshall>
if i fork the le master and bring it down local
<buzzmarshall>
can if i wanted to pull one of your branches from your repo and bring it into my local LE fork ?
<chewitt>
each logical change .. commit the change
<chewitt>
e.g. change a package; commit the change
<chewitt>
it's easy to fixup/squash commits together
<chewitt>
now .. say we merge a bunch of new stuff upstream in our repo
<chewitt>
git fetch upstream/master
<chewitt>
git rebase upstream/master
<chewitt>
now your commits are rebased on (sitting on-top off) our latest changes
<chewitt>
git push -f origin stuff
<chewitt>
now your commits are online .. in case you mess up and need to revert back to a known state
<chewitt>
if you want to work from my branch ..
<chewitt>
git fetch chewitt/amlogic-master
<chewitt>
git rebase chewitt/amlogic-master
<chewitt>
now your commits sit on-top of my branch
<chewitt>
sometimes rebase will fail as there are changes from both sides
<chewitt>
rebase is paused
<chewitt>
git status will show you the problem file
<chewitt>
file(s)
<chewitt>
edit them to resolve issues
<chewitt>
git add path/to/file
<chewitt>
git rebase --continue
<chewitt>
and it will continue
<chewitt>
the two habits to learn are:
<chewitt>
a) commit frequently .. it's simple to squash 20 changes into 2 changes and clean up; it's hard to separate 2 changes into 5 changes
<buzzmarshall>
nice... ya its allways been the whole rebase thing i get lost in but i could never find what your showing me in any of the tuts i have accumlated on git
<chewitt>
b) rebase frequently .. small minor clashes where you need to edit things are simple; large clashes get really complex .. so "little and often"
<chewitt>
learn how to use interactive rebase ..
<chewitt>
most people take a while to realise the commits can be copy/paste re-ordered
<chewitt>
which is an essential discovery; because you can only fixup or squash a commit into the previous commit
<chewitt>
so if you committed changes out of sequence, you need to put them in the right sequence first before fixup/squash
<chewitt>
once that eureka moment happens .. git suddenly gets a lot easier
<buzzmarshall>
bud... you probably just saved me a ton of hurt... im on a machine at the shop but will clip this and when i get home will use this to set that up exactly like that
<chewitt>
the bad thing is .. everyone learns git the hard way
<buzzmarshall>
ive been wondering about how to do this kinda stuff for awhile but because i don't use git much only understood the rudimentary stuff
<chewitt>
the good thing is .. everyone who learned git the hard way is happy to counsel someone behind them on the learning curve
<chewitt>
and .. everyone is still learning git
<buzzmarshall>
thats partly way in the last few years i have been shying away from trying to help out as i didnt wanna screw up someones git sources
<chewitt>
you can't screw up someone else's sources; we have branch protection in-place to stop ourselves fcuking up our own sources :)
<chewitt>
you can't push to our sources
<chewitt>
you can screw your own .. but not ours
<chewitt>
and worst case
<chewitt>
git fetch upstream master
<buzzmarshall>
for years i just hard coded my changes and then finally a ways back finally figured out how to make a patch just by setting up my own local server and then playing with one of the work stations
<chewitt>
git reset --hard upstream/master
<chewitt>
back to where you started
<chewitt>
third rule:
<chewitt>
c) always work in a topic branch .. NEVER the master (or main release) branch
<chewitt>
this ensures you can compare your changes against the branch you want to reference
<buzzmarshall>
k... ya i always create a working branch here locally when i work and leave the main one alone till i am ready to merge the working branch back into the main
<chewitt>
it means you can switch back to your local master, fetch our latest changes, switch back to your topic branch, and rebase against the (updated) master
<chewitt>
if you work in master .. changes will make will obliterate your changes
<chewitt>
you should never be merging back into your local master
<chewitt>
unless it's your own code/app/whatever
<chewitt>
in an LE context, your master should only ever track our master
<chewitt>
else you'll end up in problems at some point
<buzzmarshall>
ya i got burned on that a couple of times playin around along time ago and not understanding that
<chewitt>
"c) always work in a topic branch .. NEVER the master (or main release) branch"
<buzzmarshall>
i couldn't deal with the git error messages and got pee'd off and pitched the pile and started over again
<buzzmarshall>
lol
<chewitt>
everyone learns git by screwing up
<chewitt>
eventually you learn how to self-recover mistakes
<buzzmarshall>
slowly ive got better as i try and use it much more then i used to
<buzzmarshall>
but the mixing and matching thing you just explained was something i just couldnt quite get a good answer on
<buzzmarshall>
and finding and downloading more git tuts just seemed to add to the confusion as most never talk about that in a manner that i could really see
gouchi has joined #libreelec
<buzzmarshall>
i do really appreciate you taking the time to show me this