narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - Publicly Logged on https://irclog.whitequark.org/linux-amlogic
warpme_ has quit [Quit: Connection closed for inactivity]
bengal has quit [Ping timeout: 240 seconds]
bengal has joined #linux-amlogic
sputnik_ has quit [Remote host closed the connection]
sputnik_ has joined #linux-amlogic
ldevulder has joined #linux-amlogic
ldevulder_ has quit [Ping timeout: 258 seconds]
sputnik_ has quit [Ping timeout: 240 seconds]
asdf28 has quit [Ping timeout: 260 seconds]
sputnik_ has joined #linux-amlogic
<chewitt> @nar
<chewitt> @narmstrong @jbrunet todays interesting 'overnight splat' is http://ix.io/2C9P
<chewitt> 5.9.1 with a range of recent maliing-list items for 5.10 backported
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #linux-amlogic
bengal has quit [Ping timeout: 264 seconds]
bengal has joined #linux-amlogic
bengal has quit [Ping timeout: 260 seconds]
bengal has joined #linux-amlogic
buzzmarshall has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
chewitt has quit [Quit: Adios!]
Barada has joined #linux-amlogic
kaspter has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-amlogic
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 240 seconds]
camus1 is now known as kaspter
asdf28 has joined #linux-amlogic
TheAssassin has quit [Ping timeout: 240 seconds]
Barada has quit [Quit: Barada]
TheAssassin has joined #linux-amlogic
Barada has joined #linux-amlogic
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
trem has joined #linux-amlogic
Elpaulo has quit [Remote host closed the connection]
Elpaulo has joined #linux-amlogic
cmeerw has joined #linux-amlogic
camus1 has joined #linux-amlogic
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
trem has quit [Quit: Leaving]
Barada has quit [Quit: Barada]
chewitt has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-amlogic
sputnik__ has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 240 seconds]
yann|work has joined #linux-amlogic
yann has quit [Ping timeout: 260 seconds]
warpme_ has joined #linux-amlogic
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-amlogic
sputnik__ has quit [Ping timeout: 264 seconds]
tete_ has joined #linux-amlogic
<tete_> hi, can someone tell me when this page is refreshed? http://linux-meson.com/
<tete_> would be very interested in the current state
<narmstrong> tete_: we try to update it
<narmstrong> tete_: which state do you need ?
<tete_> i have an odroid n2, iirc its the S922x. would love to know whats with the video decoders
<tete_> i read somewhere that those should be now better supported in 5.9.x
<narmstrong> tete_: video supports mpeg2, h264 and vp9
<narmstrong> tete_: mpv can make use of it
<narmstrong> but for zero-copy playback, there is no easy solutions
<narmstrong> LibreELEC provides build for it
camus1 has joined #linux-amlogic
<tete_> atm im running libreelec but would love to use a mainline kernel
<tete_> but h265 would be nice :>
<tete_> in that case i still have to wait
<tete_> thanks!
kaspter has quit [Ping timeout: 240 seconds]
camus1 is now known as kaspter
<narmstrong> yep h265 support hasn't been pushed because it's broken on 10bit...
<tete_> can you explain that a bit ? i understood nothing :D
<tete_> i guess thats only a software problem isnt it? so might this be fixed in 5.10.x?
<gbisson> narmstrong: what about support in aosp? same decoding support when using mainline kernel/aosp?
<narmstrong> it's a sw problem, it won't be fixed soon
<narmstrong> gbisson: AOSP needs a working V4l2 Codec2 module, which is not the case yet...
<gbisson> narmstrong: ok thanks!
<gbisson> narmstrong: how far along is it? I see you've tested some part of it already: https://android-review.googlesource.com/c/device/amlogic/yukawa/+/1424772
<narmstrong> gbisson: the Chromium team is working on it, no idea when they will fix it
<gbisson> narmstrong: ok, that's good to know
<phh> + vendor/google_arc/libs/codec2 \
<phh> looks like a bad joke
<phh> (google_arc is Chromebook's Android tree, which is closed source)
<narmstrong> yeah basically it was developped on this "google arc" on a simulator
<narmstrong> in the current state there is no way it can run on a real decoder...
<adema> Is the same for s905x (potato)?
<narmstrong> it doesn't respect the S_FMT return on OUTPUT, and doesn't even call S_FMT on capture...
<narmstrong> it needs a Gralloc tweak or a vendor allocator that will behave like the video decoder S_FMT
<phh> latest commit seem to say it's being used on Pixel 5?
<narmstrong> phh: with a vendor v4l2 m2m driver and a custom gralloc and allocator :-)
<narmstrong> pretty sure their pixel 5 v4l2 m2m driver doesn't pass the v4l2 compliance
<phh> i see, thanks
kaspter has quit [Quit: kaspter]
vagrantc has joined #linux-amlogic
<damex> is there now a way to boot amlogic board without binary blobs (at reduced functionality or something?) or we still stuck with blobs and there is no way around?
* vagrantc is also curious about this question, having recently come up in debian-arm
<damex> i manage to make builds for sunxi/rockchip boards just fine but amlogic is just pain to deal with
<damex> all i am interested in is running headless debian on that amlogic board(s)
<chewitt> there are blobs needed for early boot stages, but these are available for likely all of the board devices you'd be interested in supporting
<chewitt> and the u-boot signing recipe is well understood
<damex> chewitt: well, yeah. that blobs for early boot stages... i hoped there could be a way around
<damex> s/boards/board/
tete_ has quit [Quit: Leaving]
<chewitt> ^ u-boot.bin.sd.bin
<damex> well, that is a blob ;p
<damex> so there is still no workaround exist that let you to -not-use-early-stage-blobs- ?
<adema> You can build ATF for s905x (potato)
<adema> but for the stages before ATF, you still need some blobs to setup the RAM etc
<chewitt> IIRC there is support in ATF for GXL devices now, but the bl2 code is closed source so one way or another you still need some bits from the fip sources (as I understand it)
<damex> chewitt: is there some kind of patch available based on fip sources that could be used or something?
<chewitt> to do what?
<damex> to do early init with bl2 without relying on vendor blobs
<damex> let's say you build upstream atf+uboot
<chewitt> ^ that's the signing recipe I use
<chewitt> using atf you'd replace bl30 and maybe bl301 bits .. not sure what else
<chewitt> repk did most of the work iirc
<repk> damex: yes
<damex> so <bl31 is needed from vendor sources
<repk> bl2 and bl301 are needed from vendor
<damex> repk: is there any way around ?
<repk> no
<damex> do they provide sources so you can build bl2 and bl301 yourself?
<adema> Well, you can always reverse engineer the early stages :)
<repk> bl2 initialize the RAM you need that. And no they do not provide sources for that
<repk> bl31 was reverse engineered, but bl2 and bl30 are another story
<chewitt> bl301 exists in numerous places
<repk> oups sorry meant bl30 no bl301
<vagrantc> it's amazing that someone could *possibly* confuse bl31, bl30 and bl301 ... they're so different! :)
<repk> the terminology changed IIRC
* vagrantc has to squint hard every time to make sure some number isn't typoed or transposed
<repk> now bl30 should be called scp_bl2. Don't know if it is better though :)
<vagrantc> hah
<damex> bl1 is closed source and in soc (bootrom) -> bl2 is a platform init and is closed source (blob from vendor), bl31 is atf and is opensource and and bl33 is uboot and is opensource. what exactly is bl30/bl301?
<repk> damex that is right. BL30/BL301 are firmware for the SCP
<repk> usually a cortex-M processor that control power/frequency etc
<repk> and bl32 is TEE (e.g. OPTEE).
<damex> do we really need that cortex-M3 ?
<damex> as far as i see it is supposed to be just <power management>
<damex> repk: we don't really need bl32, aren't we?
<repk> damex: no bl32 is not mandatory
<repk> damex I think bl30 is mandatory, IIRC there is a security that prevents bl33 boot if bl2 is not present (I may be wrong here), also I think a lot of clock, boost/buck, etc are controlled by SCP.
CyberManifest has joined #linux-amlogic
<damex> and bl30 is closed source too?
chewitt has left #linux-amlogic ["Adios!"]
chewitt has joined #linux-amlogic
<repk> damex: yes but it is likely based on https://github.com/ARM-software/SCP-firmware. Also you need it to have frequency scaling and booting other CPUs (at boot time only one CPU is booted)
<repk> besides that I think you can easily tweak bl31 to not boot it, don't know how usable the system will be though
<narmstrong> It would need Linux support for DVFS and bl31 support for cluster enablement, not sure if we would be able to power up the clusters without the m3
<narmstrong> The m3 handles all this
<narmstrong> For bl2 it would need to reverse all the ddr setup, this is a huge task since the hw support a large range of ddr memories automatically
<chewitt> I suspect they kept the bl2 code static, which is why we have separate firmware blobs in the fip sources
<chewitt> blobs within the blob
<narmstrong> bl2 is for the soc (they also provide some variant for some customers), the bl2 is "configured" with the acs binary containing a table to configure the ddr and system plls
<narmstrong> the bl30 is fixed for soc and loaded in the m3, the bl30 can be extended with the bl301 which is open source and handles the system suspend
<narmstrong> bl31 is fixed for the soc, and we have an open source implentation on upstrean tf-a
<narmstrong> we can mix the closed source bl2 and open source bl31 because they use the standard tf-a interface
<narmstrong> same for the optional bl32, we can either use the amlogic close source optee fork of the upstream optee, they conform to the tf-a bl32 loading interface and the standard kernel interface
<narmstrong> I'll speak about most of this on my tommorow ELC-E talk :-)
<vagrantc> a table with all the various parts mapped out would be useful, i think
CyberManifest has quit [Quit: Leaving...]
<cottsay> narmstrong: Just wanted to take a moment to say thank you for giving the wiki page some love today. I know that kind of documentation can be tedious, but I really appreciate the per-release summaries and feature tables on there, and I'm sure I'm not alone.
<narmstrong> cottsay: thx for seeing it !
<narmstrong> xdarklight: used to fill the kernel update but he has a lot of day work recently
<narmstrong> I need to update the graph up to 5.10
<cottsay> Well I appreciate both of your efforts :)
<chewitt> all we need is more people helping with the to-do list!
sputnik__ has joined #linux-amlogic
sputnik__ has quit [Ping timeout: 272 seconds]
sputnik__ has joined #linux-amlogic
<lvrp16> chewitt: who is working on rtl8822cs again? I don't want to duplicate work.
drieschel has joined #linux-amlogic
drieschel has quit [Client Quit]
drieschel has joined #linux-amlogic
drieschel has quit [Quit: drieschel]
drieschel has joined #linux-amlogic
<narmstrong> lvrp16: it’s xdarklight
<narmstrong> Another good news, I managed to reverse engineer the G12 usb boot protocol and I did a refresh of pyamlboot readme https://github.com/superna9999/pyamlboot
<narmstrong> Sadly it’s less flexible than before, we can’t load u-boot+kernel+rootfs at the same time, we need to load kernel+rootfs from Linux
<narmstrong> *u-boot
drieschel has quit [Quit: drieschel]
asdf28 has quit [Ping timeout: 256 seconds]
<lvrp16> narmstrong: thanks!
buzzmarshall has joined #linux-amlogic