blackest_mamba has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
St3ak has joined #libreelec
andy-burns has joined #libreelec
psymin has joined #libreelec
ponyofdeath has joined #libreelec
blackest_mamba has joined #libreelec
Gittun has quit [Quit: UPP]
iNDi has quit [Ping timeout: 258 seconds]
iNDi has joined #libreelec
Kostenko has joined #libreelec
Fenster has joined #libreelec
<Milhouse>
@EuroTrash: No, everything is in the build.* folder so if you remove that folder and build again you'll be building "clean". If you still have a problem it's likely your tree is broken somehow (as you suspect)
<Milhouse>
Kocane: The tearing is a known (and very important) issue - it had been fixed in a fairly recent 5.x kernel but is currently broken again as there's a lot of backend video related changes going on some of which introduce regressions. Don't worry though, it's definitely something that will be fixed, permanently, eventually!
buzzmarshall has joined #libreelec
_abbenormal has quit [Read error: Connection reset by peer]
_abbenormal has joined #libreelec
_abbenormal has quit [Read error: Connection reset by peer]
_abbenormal has joined #libreelec
_abbenormal has quit [Read error: Connection reset by peer]
_abbenormal has joined #libreelec
mETz has quit [Ping timeout: 240 seconds]
mETz has joined #libreelec
speeedy has quit [Read error: Connection reset by peer]
psymin has quit [Quit: Leaving]
donofrio has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #libreelec
buzzmarshall has quit [Remote host closed the connection]
andy-burns has quit [Ping timeout: 272 seconds]
blackest_mamba has quit [Remote host closed the connection]
andy-burns has joined #libreelec
_abbenormal has quit [Read error: Connection reset by peer]
_abbenormal has joined #libreelec
_abbenormal has quit [Read error: Connection reset by peer]
_abbenormal has joined #libreelec
blackest_mamba has joined #libreelec
andy-burns has quit [Ping timeout: 265 seconds]
andy-burns has joined #libreelec
andy-burns has quit [Ping timeout: 268 seconds]
hijacker has joined #libreelec
self has joined #libreelec
_fraggle_ has quit [Remote host closed the connection]
ghostcube has joined #libreelec
emOne has quit [Ping timeout: 240 seconds]
donofrio has joined #libreelec
self has quit [Ping timeout: 260 seconds]
<Kocane>
Milhouse: Sounds good :-) do you know anything about the deinterlacing methods available? Something about bob being the only one that is actually used on the RPi4 despite selected "advanced" which should be Yadif
<EuroTrash>
Yeah, that's a drawback, but not really within the intended use cases. Though I've had to resort to that sort of stuff on x86 to get access to some nasty DRM'ed legitimate services a couple of times.
<emOne>
DRM and widevine DRM is truly terrible
<emOne>
I have a feeling that there is a big bandwidth conspiracy going on
<EuroTrash>
Yeah, number of times it prevented content copying: 0. Number of times I benefited from it as a user: 0. Number of times it pissed me off because I couldn't play stuff the way I wanted to, even though I legitimately was allowed to play it: 12,376 times and counting
<emOne>
hahahah yes
<emOne>
unless ofc you play it back on your phone screen then you are allowed to view it in 4k
<emOne>
just make sure you put your phone on your face so you can see all those pixels
<EuroTrash>
There are bandwidth conspiracies going on, though in the DRM field, it's mostly services trying to please the ever-knee-jerking media conglomerates with some false sense of security.
<emOne>
It reminds me of the apple itunes library when it started selling tv shows and movies
<emOne>
I remember people complained about them not being in 1080p
<emOne>
I am sure those were also DRMd
<EuroTrash>
Yeah.. but I'm pretty sure even the Apples and Netflixes don't really want DRM. It's just that they flat out won't get the licenses if they don't please the boardroom members at Big Media.
<emOne>
and of course the DRM doesn't stop the content being dumped anyway
<emOne>
it only annoys those people that enjoy the highest quality
<emOne>
but it seems that the masses can't tell the difference between 480p and HDR
<psymin>
iirc it was associated with kiosk mode or something
<psymin>
and might still need X or whatever :P
<psymin>
"Launch websites via selected Browser in Kiosk-mode"
<psymin>
heh, might be win only
<emOne>
fair enough
<emOne>
still a cool idea
<emOne>
maybe it is just kodi that needs an updated way to run apps
<emOne>
those python based apps using the kodi interface start to look dated
<psymin>
python is powerful
<emOne>
python isn't the issue here
<emOne>
it is the gui framework
<emOne>
enigma OS which was made to run on set top box hardware from ~1994-1995 also uses python for the apps
<emOne>
or c/c++ for some of the more complicated non-community made stuff
<emOne>
but anything that used the interface used python
<emOne>
it still does to this day
<emOne>
kodi was amazing when it was released, and still is to this day
<emOne>
and nothing was able to come close to it
<emOne>
but other propriatry systems have started overtaking it imho
<psymin>
xbmc ftw :)
<emOne>
yes!!!!!!
<emOne>
running xbmc on the xbox was the best thing ever
* psymin
nods.
<psymin>
gentooX
<emOne>
add some divx or xvid discs and it was a good ay
<emOne>
day
<psymin>
picked up a few of those units just to run xbmc on
<psymin>
too bad the dvd drives flaked out eventually (laser / head issue or something)
<emOne>
yes those wore good times
<emOne>
mhm
<emOne>
and also no HDMI heh
<emOne>
otherwise I would still be using one
<psymin>
I think an rpi4 blows it out of the water
<emOne>
I only have a rpi2 or so
<emOne>
and some rpi zeros
<emOne>
but yes, I would imagine it does
<psymin>
I wonder if it would be worth trying to put libreelec on that old device. Might be a bit of brain damage.
<emOne>
ahahah
<emOne>
yes
<emOne>
it only had 64mb of ram or so afaik?
<psymin>
oh my
<emOne>
yes
<psymin>
yep
<emOne>
so it was pretty cool what the modders managed to port to that system at the time
<psymin>
wow, that was about 18 years ago
<emOne>
the kodi gui needs to start supporting 3d graphics in my opinion
Fenster` has joined #libreelec
<psymin>
I disagree. My stubborn opinion is that 3D has no place in a GUI. I dislike all that compositing stuff :P
<emOne>
me neither to be honest
<emOne>
it just feels like apps lack ways to draw using the kodi gui framework
<emOne>
the themes look great
<emOne>
apps on the otherhand don't
<emOne>
psymin: it was 18 years ago
Fenster has quit [Ping timeout: 240 seconds]
<buzzmarshall>
i still run a couple of old xbox's with xenuim's and it was xbmp back then, some of the rom emulators from back then still run better then on the much faster arm based android boxes people are using now
<emOne>
but it only became xbmc as we knew it later on
<psymin>
OT: on an x86_64 (wyse thin client) install of libreelec, sometimes both cores get maxed while watching netflix. During that time audio sync issues and potentially network issues.
<buzzmarshall>
its just the conveniance of the newer devices with LE and Kodi that make it much nicer
<psymin>
LE is quite convenient
<buzzmarshall>
old xboxes were basically old Intel P3 700's and i once tried sticking OE on it before LE forked
<buzzmarshall>
could never quite get it to work right tho
<emOne>
it was amazing how well the emulators ran on it
gouchi has quit [Remote host closed the connection]
<emOne>
xbmc + emulators was the perfect media system
<buzzmarshall>
ya there ran really nice as most of that old code ported nicely to the old intel hardware at the time
<emOne>
we spent so much time playing neo geo roms on the xbxo
<emOne>
clever coding is the way to go
<buzzmarshall>
arm's a totally different animal these days and most dev's work at one of the higher languages these days were back then anyone really hacking were assembly level coders
<emOne>
n64 emulators used an interesting approach. Those emulators managed to run on pentium 2 hardware
<buzzmarshall>
not many mess with assembly anymore
<buzzmarshall>
ya your right
<emOne>
I think someone discovered that it used a similiar technique to glide or opengl , and just wrote a dictionary for those instructions
<emOne>
to translate n64 opengl to normal opengl
<buzzmarshall>
the newer arm based units are really nice the main issue tho with all of them is mostly around the gpu and most SoC makers using propriatary cores for the onboard gpu hardware
<emOne>
yes
<buzzmarshall>
most of the current efforts i think as much headway as they have made
<buzzmarshall>
which is really good lately
<emOne>
the whole proprietary software which only works on android (which runs ontop of linux) is killing me
<buzzmarshall>
but its still hindered by those devs being high level peeps trying to quess at the hardware ip cores
<emOne>
yes
<buzzmarshall>
man i hate android on these devices
<emOne>
that is good and bad imho
<emOne>
hahh yess
<buzzmarshall>
its a touch screen os and not got anyplace in this area
<emOne>
high level devs are needed as much as low level devs
<buzzmarshall>
ive been puttin linux on android devices since the old dreams
Fenster` has quit [Ping timeout: 265 seconds]
<buzzmarshall>
kodi really works nice on linux on the devices
<buzzmarshall>
just companys like Amlogic and others arent interested in it
<emOne>
they really need to start making their drivers open source
<emOne>
I ordered some boxes from china
<buzzmarshall>
they're making their margins doing it the way they always have and left the linux scene mostly on top of the public's shoulders
<buzzmarshall>
ya i agree
<emOne>
but yes, it sounds like that is true
<buzzmarshall>
but seein as they keep using Arms Mali cores theres no way its gonna happen
<emOne>
that there are less low level coders that are around
<buzzmarshall>
its IP'd and Arm makes its money either selling licences or the actual hard cores
<EuroTrash>
It's not so much about the coders as it is about lack of documentation or even NDAs making it impossible for anyone to code for it.
<buzzmarshall>
other then the S922's all the old ones have been privately fixed for awhile now
* emOne
still can't get the mt7668 wifi chip to work
<buzzmarshall>
those SoC's have been decapped and studied and modelled but producing public blobs is a big issue
<buzzmarshall>
ya the docs is a big problem
<emOne>
blobs only became an issue in the world of arm cpus
<EuroTrash>
I mean, what kind of important secrets are in these things anyway, it's just a stupid GPU.
<emOne>
lol yes
<buzzmarshall>
without them you need to look at the hardware and use existing blobs to study whats going on
<emOne>
is a blob just a binary?
<buzzmarshall>
its like a black box where you know what going in and coming out but not how its done internally
<emOne>
the first time I heard of blobs was when raspberry pis were released
<EuroTrash>
emOne: yes, usually in the form of either (part of) the driver or firmware that gets uploaded in runtime.
<buzzmarshall>
yes the blob is a binary without source but it enables the OS to properly use the Ip Cores api
<buzzmarshall>
thats how Arm protects the actual mali code
<EuroTrash>
Ah yes, "protecting" :P
<emOne>
heheh
<buzzmarshall>
usually something like that will be developed in something like vhdl or verilog and then fab into the endusers SoC by what ever foundry they have making the chip
<EuroTrash>
"I'm not locking you up in my basement, I'm protecting you!"
<buzzmarshall>
lol
self has joined #libreelec
<buzzmarshall>
here whats kinda happened is the SoC makers paid for licenced blobs for Android
<emOne>
are you saying that the blobs are there to protect the actual design of the chip?
<buzzmarshall>
that way the canned version of Android they provide to the downstream factories works on the gpu hardware
<buzzmarshall>
ues
<buzzmarshall>
think of it like this for to keep things easy
<buzzmarshall>
think of the ip core kinda like the rom code for mario brothers in the chip
<buzzmarshall>
in that case the os or controling system knows how to use because it understands how to talk to it and use it
<buzzmarshall>
its not really intended for the user to see
<emOne>
and there is nothing wrong with that imho
<emOne>
yes
<buzzmarshall>
in the case of the SoCs being made these days they are basically big ASIC's
<emOne>
software defined hardware
<emOne>
got it
<buzzmarshall>
Asics are basically hardware cells that can be formed to create the logic you want
<buzzmarshall>
so ontop of the normal Arm core used to run things they also put some other ip cores into the same basic physical chip
<emOne>
so basically those chips are programmed
<buzzmarshall>
ya
<emOne>
got it
<emOne>
and if the blobs were open sourced so would be the design of the chip
<buzzmarshall>
all that core code needs to have a set of known command structure to make use of it
<buzzmarshall>
for the most part the main core's Arm's are all published and easy for any dev to learn to use and do whatever with
<buzzmarshall>
in the case of the Mali cores that information is controlled
<buzzmarshall>
and theres a set of tools that go with it to develop on
<emOne>
why can you not run armbian on an rk3318 chip for instance?
<buzzmarshall>
so with the current guys attempts they are trying to build on that knowledge pool and work from there
<emOne>
^
<buzzmarshall>
no real reason you can't
<emOne>
maybe it already works
<buzzmarshall>
the issue with most of all the devices is the lack of using the onboard hardware for video in some areas
<emOne>
but the last time I checked there wasnt a way
<emOne>
got it
<buzzmarshall>
so depending on what platform your on they tend to vary somewhat in how well its supported
<buzzmarshall>
most rockchip devices were slightly ahead because in general Rockchip was more forth comeing in making info available then say Amlogic
<buzzmarshall>
but they all tend to vary
<buzzmarshall>
and they to compound it some of the flavors of the fully linux distros are better then others
<buzzmarshall>
again it kinda comes back to just what and how your trying to drive the graphics portion of the build
<buzzmarshall>
Arm's already publicly stated its got no use for X11 anymore
<EuroTrash>
There's a bunch of hardware setup happening, most often in uboot or some proprietary boot system, and these chip manufacturers and/or integrators tend to not release the source for that. But given enough demand for the platform, a lot of that is often figured out by the community. But end of the day, that stupid rockchip thing still has the Mali GPU.
<emOne>
"buzzmarshall: Arm's already publicly stated its got no use for X11 anymore"
<emOne>
why is that?
<buzzmarshall>
so thats been a bit of a pain cause it needed to be done by others
<buzzmarshall>
not really sure other then seeing in Arms Mali dev areas
<buzzmarshall>
personally i think they just don't see this part of the market as anything other then a Android thing so the current licencing schem is fine with them
<buzzmarshall>
i did see some mention of wayland down the road maybe but who know
<emOne>
here is to Huawei making a nice alternative to android
<buzzmarshall>
they like the blob thing as it generates huge bucks for them
<buzzmarshall>
and they can control the revisions
<emOne>
it might be interesting to see what happens with Huawei releasing HarmonyOS
<buzzmarshall>
thats partly whats stalled linux on the vendors bsp's
<emOne>
they said it is going to be fully open source
<EuroTrash>
And they don't get burned on github for their shit code
<emOne>
EuroTrash: a Mali gpu? Is that good or bad?
<buzzmarshall>
with Huawei's current status in the five-eyes group im not sure how much headway they will make here in NA tho
<EuroTrash>
Mali has the blob, so even with said Rockchip device fully supported, it'll end up with the same issue as all of these boxes: poor hardware video decoding support.
<emOne>
whats the best GPU for arm socs?
<buzzmarshall>
GPUs' are probably next to secure smart cards one of the most controlled and closed areas in the coding industry
<emOne>
buzzmarshall: maybe not in NA
<emOne>
but is nice that they are making an alternative OS
<EuroTrash>
Dunno if there is any.
<buzzmarshall>
thats why Arm and NVidea and AMD/ATI are so picky about stuff
<buzzmarshall>
personally i see nothing wrong with Linux itself as the OS
<EuroTrash>
Even the Pi is horribly closed. It's just better because the Pi organisation has some leverage and motivation to get a reasonably working blob from Broadcom
<buzzmarshall>
its just in this case most of the arm based devices you see around here have Arm Mali Ip Cores in them
<buzzmarshall>
Broadcom is another company that tightly controls their stuff
<emOne>
to be fair I am surprised no one managed to find a work around to get mpeg2 to work on the pi
<emOne>
without paying for the microcode
<buzzmarshall>
i used to mess around with alot of them in the old settop sat industry
<buzzmarshall>
to be honest all of them are actually pretty good its just this protection of the GPU cores that are causing the grief
<EuroTrash>
emOne: well if it was mpeg4 instead of mpeg2, things would have been different. But mpeg2 was already thoroughly on its way out even when the first Pi came out, so no one really bothered.
<buzzmarshall>
all of the other things still somewhat lacking a bit are able to be overcome
<EuroTrash>
buzzmarshall: yeah... except wifi, though. Very similar situation for e.g. OpenWRT
<emOne>
<3
<EuroTrash>
So much Broadcom doesn't work
<buzzmarshall>
one thing that kills me is that so many people hate Apple because of its controlling nature in trying to deliver a end-to-end solution for its users
<buzzmarshall>
yet with this crap its exactly the same way
<EuroTrash>
Take almost any random Broadcom router, you can install openwrt on it without too much trouble, will run fine, except you'll never be able to use the wifi part, making the entire endeavor quite futile.
<buzzmarshall>
they all use SoC's where they basically hinder peoples attempts by controlling the GPUs
<emOne>
I remember facing a lot of trouble using broadcom wifi
<buzzmarshall>
broadcoms chipset are huge in the router market
<emOne>
I always have bad memories regarding broadcom
<buzzmarshall>
thats gotta be a big area for them
<emOne>
they were huge in the set-top-box market too
<emOne>
and yes, routers and modems
<buzzmarshall>
yes but at least that wasn't their forte cause none of that crap was that hard to mess with
<buzzmarshall>
st-micro's code was much tougher
<buzzmarshall>
its just to bad some of the other Arm core makers don't move into this market
<emOne>
atheros <3
<buzzmarshall>
company's like Ti or St
<buzzmarshall>
they tend not to use gpu's protected in this manner
<emOne>
atheros for wifi <3
<emOne>
the whole arm soc market is just confusing for the linux scene
<emOne>
and to be fair I am surprised prominent linux figures like Linus Torvalds has not made any statement about this
<emOne>
whenever he spoke out about someone not following the open source ideology there would always be some sort of response
<emOne>
is there something I am missing?
<emOne>
is it maybe because arm chips kind of quietly became a major player while the community was using x86?
<buzzmarshall>
i don't think so
<buzzmarshall>
ive been using linux since he 1st started and the slackware packages appeared and think he just worrys about the kernel and realizes how things have exploded with embedded devices
<buzzmarshall>
so kinda goes with the flow these days
<emOne>
yes
<buzzmarshall>
i think he expresses himself when it comes to taking the upstream pushes from others
<buzzmarshall>
so if he's upset with something i think he deals with it their
<buzzmarshall>
the embedded market has gone nuts in the last few years as more and more appliance types of devices come out
<buzzmarshall>
actually LE is a big part of the ongoing change
<emOne>
arm based fridges have become a thing
<buzzmarshall>
at the risk of loosing patrons they are looking at the long game trying to get everything up onto mainstream
<buzzmarshall>
and helping push Kodi up thru the python 3 move
<buzzmarshall>
that in the end will make a huge impact for anyone down the road wanting linux support on their device
<emOne>
python is not an issue
<emOne>
imho
<emOne>
the gui is outdated
<emOne>
apps need easier ways to draw onto the screen
<buzzmarshall>
i tend to agree but its old by todays standard and i can see why its being done
<emOne>
yes of course.
<buzzmarshall>
its good that they do it now while trying to make the linux mainstream
<emOne>
yes
<buzzmarshall>
the mainstream thing is a big hurdle and who knows how it will pan out in the end if it ever does
<emOne>
but kodi also needs to let apps use opengl
<buzzmarshall>
so might as well see Kodi make the move now as well
<emOne>
mainstream thing?
<buzzmarshall>
sorry... i mean getting the linux kernel up onto the mainstream sources
<emOne>
oh okok
<buzzmarshall>
no more propriatary bsps
<emOne>
yes
<buzzmarshall>
things like the device tree came into the mainstream linux years ago as a method to try and put some inteligence into the perpherals on the board
<emOne>
there were some news about Linus complaining about zfs, i think, recently
<emOne>
the device tree is completely new to me
<buzzmarshall>
there trying to make the kernel easier for dev's to use
<emOne>
an to me it looks like a complete mess
<emOne>
the device tree and dtb files seem messy
<emOne>
but who knows
<buzzmarshall>
actually its pretty good once you understand it but your right it can be messy as things are being put into place
NGC3982 has quit [Ping timeout: 260 seconds]
<buzzmarshall>
here i will try and use something like the old S812
<emOne>
for a kernel dev I am sure it is great since the kernel has kept growing
<buzzmarshall>
most say its not usable these days but thats not really true
<emOne>
go on
<buzzmarshall>
the issues really are routed in the fact that Amlogics bsp support used old 3 kernel
<buzzmarshall>
with a bunch of crappy code of their own
<buzzmarshall>
then came the newer gen of boxes with 3.14 and the same problem
<buzzmarshall>
meanwhile at pretty much the same time period the mainstream kernels were at 4 and then went to 5 where they currently are
<buzzmarshall>
so on the old box those binary blobs for the mali gpu's were tied to the old kernel
<buzzmarshall>
and for the linux guys in a lot of cases it was to much to take on trying to migrate things up
<buzzmarshall>
still is for a large part of them
<buzzmarshall>
so the new boxes come and go as all the device vendors just keep pumping new devices out
<emOne>
is the company not interested to do it?
<buzzmarshall>
nope
<buzzmarshall>
hell Amlogic was introducing the whole S9xx line before the older S8xx market even had decent running software
Fenster has joined #libreelec
<buzzmarshall>
back to the old thing for moment
<emOne>
yes yes
<buzzmarshall>
the idea behind mainstream and things like the device tree stuff was to provide a method for the device makers to basically just have to use mainstream linux kernel and then to provide their dtb files upstream
<buzzmarshall>
thats a simplified explanation and theres more to it
<emOne>
that makes sense .. kind of
<buzzmarshall>
but the idea was to not have the linux community have to bear the time and resources to figure out how to get linux on the device and a more organized manner
NGC3982 has joined #libreelec
<emOne>
has it worked?
<buzzmarshall>
in the old days say i wanted a particular wifi card
<emOne>
yes
<buzzmarshall>
if it wasnt in the normal prebuilt kernel found in most distros
<buzzmarshall>
i would have to find the device files and put them into my build and recompile the kernel
<emOne>
go ob
<buzzmarshall>
over the years the 1st thing that came was the ability of the kernel to handle modules dynamicall
<buzzmarshall>
so that was kinda the 1st step
<buzzmarshall>
thats now all old hat stuff
<emOne>
it is a monolithic kernel after all
<buzzmarshall>
then came the idea of inteligence for peripherals
<buzzmarshall>
you know how say something like usb is kinda auto detected by most operating systems
<emOne>
yes
<buzzmarshall>
thats because usb is standardized and some what smart
<buzzmarshall>
a lot of other peripherals tho arent
<buzzmarshall>
so they need a method of telling the kernel hey look at me
<buzzmarshall>
thats part of the idea behind the Device Tree thing
<buzzmarshall>
now
<emOne>
got it
<buzzmarshall>
because pretty much any system needs something to pull it up
<buzzmarshall>
we see things like bootloaders
<emOne>
which is another issue in the world of arm
<emOne>
which was not an issue in x86
<buzzmarshall>
ture
<buzzmarshall>
sorry bad typing
<buzzmarshall>
true
<buzzmarshall>
bootloaders built outta a few chunks of code
<emOne>
what do you mean?
<buzzmarshall>
so when the chip boots up it uses the bootloader to setup the memory and things like the stack and com port
<buzzmarshall>
it uses that dtb file in doing so
<emOne>
got it
<buzzmarshall>
k... when the SoC starts up it eventually jumps to a known point in memory
<buzzmarshall>
at that point will be the location to go and find some code and move it into the sram contained inside the soc
<emOne>
ok
<buzzmarshall>
once that code runs it constructs the memory structure and creates the stack in the boards ram
<emOne>
which worked well in x86
<buzzmarshall>
after that the running code will be loaded until finally the kernels up and running and init take overs
<buzzmarshall>
same idea basica
<buzzmarshall>
pc's use bios for a big part of that
<buzzmarshall>
u-boot is common on Arm but theres lots of others as well
<buzzmarshall>
u-boot can be built in chunks
<emOne>
yes I saw that uboot is also used in a lot of embedded devices
<emOne>
routers
<buzzmarshall>
pretty much anything arm uses sometype of bootloader
<emOne>
so are you saying standardisation is the biggest problem in arm devices?
<buzzmarshall>
no thats all standardized
<buzzmarshall>
arms really more of a instruction set architeture thats been standardize to the point that anyone can either licence or buy cores
<buzzmarshall>
coming from a pc background tho it can kinda be wierd
<buzzmarshall>
because theres things the normal pc programmer are kinda insulated from that need to be dealt with in the arm arena
<emOne>
like what?
<emOne>
I am reading over the things that you have been explaining
<emOne>
about the dtb file being used by the bootloader
<emOne>
does this also happen in normal x86 linux distros these days?
<emOne>
I guess not right?
<buzzmarshall>
most pc programmers basically just deal with having to learn to code for the os the pc runs on without worrying about things like bootstrapping the device
<buzzmarshall>
not any real need for a bootloader on a pc
<buzzmarshall>
things like the bios handles alot of that
<buzzmarshall>
let me try it this way
<emOne>
ok I think I understand
<buzzmarshall>
with a pc when it boots up normally the programmer on windows or mac os don't need to worry about the memory array
<buzzmarshall>
things like timing and bus width and amount
<buzzmarshall>
its all handled by the motherboard
<buzzmarshall>
these devices aren't like that as Arm is more like the command set of the main controller
<emOne>
I didnt understand any of that
<emOne>
hehe sorry
<buzzmarshall>
but from a hardware point of view knows nothing other then what its feed to for information on that stuff
<emOne>
buzzmarshall: these devices aren't like that as Arm is more like the command set of the main controller
<emOne>
what is the main controller in this case?
<buzzmarshall>
the SoC or lets just say the S905
<emOne>
got it
<emOne>
oh okk
<buzzmarshall>
the S905 is a System on Chip which runs the show
<emOne>
which is not "arm"
<emOne>
I understand
<emOne>
it is confusing
<emOne>
but yes
<buzzmarshall>
yes it can be
<buzzmarshall>
techinically this aint really correct but try and think of it like this
<emOne>
got it
<buzzmarshall>
the S905 is a big flash chip
<emOne>
with a lot of different files? :)
<buzzmarshall>
in it we program the Arm core for the Instruction set we wnat to use
<emOne>
and mpeg2
<emOne>
and mp3
<emOne>
and mpeg4 vc1, soundcard , gpu etc?
<buzzmarshall>
in this case we use the ARM Cortex one
<buzzmarshall>
yes all of that stuff gets supported as well
<buzzmarshall>
some of it will be in code inside the S905 while some others may be external periferals on the board
<buzzmarshall>
things like say a wifi-bluetooth chipset
<emOne>
heh yes
<buzzmarshall>
so all of that stuff is being run from and under the control of the s905
<buzzmarshall>
so now when we start the chip up we need to have a method of telling the s905 what it needs to startup
<buzzmarshall>
it needs to know how much and where is its memory
<buzzmarshall>
needs to form a stack
<buzzmarshall>
and then it needs to load the operating system
<buzzmarshall>
u-boot handles that
<buzzmarshall>
but because the amount of sram inside the actual s905 is very small we can't stick alot of code in there
<buzzmarshall>
instead what they do is
<emOne>
mhm
<buzzmarshall>
like all processors theres a vector area that gets landed on once the chips done initializing itself
<buzzmarshall>
none of thats changeable
<buzzmarshall>
its masked into the chip
<buzzmarshall>
but where it ends up once its running knows where to jump to and look for what to start running
<emOne>
is that vector area always differnt?
<buzzmarshall>
no
<buzzmarshall>
the vector table is always fixed and where the interrupts are hooked from
<buzzmarshall>
so there will be a whole bunch of them both for the chip and for the peripherals its using
<buzzmarshall>
there all fixed
<emOne>
but different in each chip type ?
<emOne>
for example the s905 and another arm cpu
<buzzmarshall>
so once the chips running it goes the reset vector that points it where to look to begin
<emOne>
got it
<buzzmarshall>
yes it can be as thats up to the manufacturer of the SoC
<buzzmarshall>
they can put it where evey they want but most tend to stick to patterns
<emOne>
but it is masked into the chip
<buzzmarshall>
in the case of some its the top of the memory area the chip can address while with others it someplace else
<emOne>
so I guess it is not so relevant for this conversation... it is just that it might be interesting for some modding purposes
<emOne>
yes
<emOne>
okok I understand
<buzzmarshall>
well its great to know because to be honest the way its being use here is not the only way things can be done
<buzzmarshall>
most don't go this low as they program up higher which is ok in most cases but if you really want to hack the hardware its good to know
<emOne>
we talked about the original xbox
<emOne>
which of course could not boot linux or any other code
<emOne>
without hacking it
<buzzmarshall>
k
<buzzmarshall>
what kinda happened with them was that like a pc cause thats really what it was
<emOne>
yes
<buzzmarshall>
a hardware chip was used to intercept the bus and hijack the startup
<buzzmarshall>
usually that chip was a cpld or small fpga that gave it the smarts
<emOne>
later it was a soft mod
<buzzmarshall>
originally tho the hack came as a result of getting in thru app
<buzzmarshall>
yes
psymin has quit [Quit: Leaving]
<emOne>
I think we bored psymin to death
<emOne>
lol
<buzzmarshall>
haha
<emOne>
didn't the softmod abuse the vector point of the cpu?
<buzzmarshall>
ya that would be me as i never shut up
<emOne>
nahhh it is interesting !!!
<buzzmarshall>
i don't take the time to sit in the public and then end up babbling away
<emOne>
that's what IRC is for
<buzzmarshall>
haha
<buzzmarshall>
for sure
<emOne>
but yes I know the softmod used a buffer overflow to trigger the P3 cpu to reset to a specific memory address
<buzzmarshall>
all the old hackers still sit in private rooms
<buzzmarshall>
thats all we know
<buzzmarshall>
the modern guys seem to now use pay sites
<emOne>
pay sites?
<buzzmarshall>
yes thats right
<buzzmarshall>
their like private forums where groups work
<emOne>
fair enough
<buzzmarshall>
there basically just closed to the public for whatever they are working on
<buzzmarshall>
but usually cost money by whoever provides the service
<emOne>
ohh ok
<emOne>
I didn't realise that
<buzzmarshall>
your right tho about the software
<buzzmarshall>
that works because of what i said about the vector table
<emOne>
back to arm
<emOne>
yes
<buzzmarshall>
pretty much every chip maker these days makes the basic user/developer guides availabe
<buzzmarshall>
and the instruction set and vector tables aren't really things they hide
<buzzmarshall>
as they are basic functionality built into the chip that anyone developing would need to know
<buzzmarshall>
anyways with the arm
<buzzmarshall>
once the reset vector is called it to like the old xbox always goes to a known memory location
<buzzmarshall>
that will then lead it to the startup and initialization code which is really what u-boot is
<buzzmarshall>
it could be any bootloader but here most of these devices are using u-boot
<emOne>
yes
<emOne>
I noticed
<buzzmarshall>
thats because u-boot was part of the Amlogic BSP which is where most into linux started