<vagrantc>
hey folks ... trying to package arm-trusted-firmware for debian to be able to support more boards out-of-the-box ... but i get strange results with the bl31.bin ...
<vagrantc>
it appears to be a sparse file of about 100k, but the file is listed as 4GB ... presumably a sparse file ?
<vagrantc>
also, the rk3399 target fails to build m0, as it can't find arm-none-eabi-gcc ... but arm-none-eabi-gcc is definitely present in /usr/bin ... where is it looking for it?
amstan has quit [Ping timeout: 252 seconds]
amstan has joined #linux-rockchip
amstan has quit [Changing host]
amstan has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<beeble>
vagrantc: that is kind of unavoidable with the rockchip atf linker script. thats why we splitted the m0 firmware out into a standalone project
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-rockchip
<vagrantc>
beeble: what's unavoidable about it?
<beeble>
the 4gb output
<vagrantc>
beeble: well, the 4GB output happens on the rk3328 as well, which doesn't have m0 as part of the build
<wzyy2>
It seems actually no one have test upstream arm-trusted-firmware before...
<vagrantc>
wzyy2: well, i'm trying to package "upstream" ... as packaging every vendor fork under the sun isn't really viable for Debian
<wzyy2>
just for test
<vagrantc>
unfortunately, that often means some boards are just unsupported
<vagrantc>
yes, i want to get beyond testing :)
<vagrantc>
wzyy2: looks like, at this moment, they're identical
<vagrantc>
which is impressive :)
<wzyy2>
Yeah, it's not vendor fork.. This fork is used to store their upstream develop tree, to create pull requests.
* vagrantc
cheers
<vagrantc>
alas, whatever issues i'm facing aren't solved by using it, then. :/
cnxsoft has quit [Ping timeout: 255 seconds]
lurchi_ has quit [Remote host closed the connection]
lurchi_ has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
<beeble>
vagrantc: the issue is that the m0 firmware is located at the end of the memory and the atf at the start. trustmerger somehow strips the padding inbetween but with mainline u-boot your are (currently) out of luck if the parts are not standalone. for the fit loader
<beeble>
but i have to check whats the longtime plan is that setup. atf seems to be able to load .elf now. so i'm not sure if we are planning to switch over to let atf load it or something else
descend-irc has quit [Quit: Connection closed for inactivity]
chen_ has joined #linux-rockchip
wzyy2 has quit [Remote host closed the connection]
afaerber has quit [Quit: Leaving]
chen_ has quit [Ping timeout: 248 seconds]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
afaerber has joined #linux-rockchip
chen_ has joined #linux-rockchip
amstan_ has quit [Ping timeout: 255 seconds]
amstan has joined #linux-rockchip
amstan has quit [Changing host]
amstan has joined #linux-rockchip
hramrach has quit [Ping timeout: 240 seconds]
hramrach has joined #linux-rockchip
amstan has quit [Ping timeout: 260 seconds]
amstan has joined #linux-rockchip
amstan has quit [Changing host]
amstan has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
chen_ has quit [Ping timeout: 258 seconds]
wzyy2 has joined #linux-rockchip
<LongWork>
would anyone here be kinda techy on gles / egl stuff ?
<LongWork>
i am wondering if there is a way after using dmabuf import to create a texture to know the sampling format of the output image
<LongWork>
the EGLImage that is created
<LongWork>
it seems that on Mali this will come out as an RGBA image, but i was wondering if there was some "standard" way to retrieve that information
<micken>
mmind00: Perhaps you have a clue about this. I have rewritten my HDMI code only to come to the fact that the PHY doesn't lock. I have seen that Linux checks LOCKONCLOCK if the PHY_STAT0 doesnt have bit 0 set. I am doing the same thing, and the onlyclock in LOCKONCLOCK is the pixelclock.. How do I intepret that, is TDMS supposed to lock?
JohnDoe_71Rus has joined #linux-rockchip
chen_ has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
wzyy2 has joined #linux-rockchip
chen_ has quit [Ping timeout: 260 seconds]
wzyy2 has quit [Ping timeout: 255 seconds]
wzyy2 has joined #linux-rockchip
nasuga has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
wzyy2 has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
nasuga has quit [Ping timeout: 258 seconds]
wzyy2 has quit [Ping timeout: 255 seconds]
chen_ has joined #linux-rockchip
vagrantc has joined #linux-rockchip
chen_ has quit [Ping timeout: 248 seconds]
chen_ has joined #linux-rockchip
chen_ has quit [Ping timeout: 255 seconds]
chen_ has joined #linux-rockchip
<LongWork>
phh : you around ?
<phh>
yes?
<LongWork>
hey :) I was discussing with mpv dudes, and we were trying to figure out a proper way to find out what type of texture eglCreateImageKHR would create (ir RGBA / NV12 etc)
<LongWork>
it seems from my experience that with mali, that will always generate an RGBA texture
<phh>
I've already read your question :P and no, I don't know
<LongWork>
and it also seems that there is no way in EGL to get that kind of info, and that it is sort of vendor dependent
<phh>
EGLimage is supposed to be opaque
<LongWork>
i'm wondering if it's some common behavior of Mali GPUs, like if eglCreateImageKHR will always create an RGBA image on mali
<LongWork>
because for instance, with vaapi on intel, you could get an NV12 output texture
<phh>
imo, it could output the proprietary compressed format
<phh>
LongWork: but I'm not too sure, why are you putting the video into opengl, if it's not to render it using EGL?
<LongWork>
it is in this csae, but for some reason mpv needs to know the output format
<phh>
I don't understand, isn't gles/egl a video output?
<LongWork>
i had set that to RGB0, but as the renderer is becoming rather stardard (not only rockchip), that kind of assumption is bad
<phh>
why would it have an output format?
<LongWork>
when you create a texture, there is a DRM format as input and some data (stride handles and such)
<LongWork>
but the created texture can be in a different format
<LongWork>
ie on mali, from DRM_FORMAT_NV12, it will create an RGBA texture
<LongWork>
the problem seems to be that the format that the texture will be created in is determined by the driver
<LongWork>
and there is no way to know what it is thru the OpenGL API
<LongWork>
because mpv needs it for something, I dunno what for because i didnet dig all the code, but it's required at some point by the mpv API
<LongWork>
ir might be to determine what type of shaders are used afterwards or something
<LongWork>
i beleive that some shaders that are used then need to know what format that texture comes in so that they can do some processing. and with vaapi, they could have NV12 textures
<LongWork>
so the shader code wouldn't be the same for peeking and poking data
<LongWork>
So teh conclusion of the discussion we had was that we could somehow as the API doesn't provide a way to query this, maybe parse the egl string ... it's ugly but would help determining that we have mali and therefore set RGBA.
<phh>
IMO it will always be RGBA
<phh>
I mean, every single video game uses shaders, if the format of the texture magically change, you break 2/3 of the world
<LongWork>
but i was wondering if any Mali would have that behavior to create RGB textures when you create such textures
<vagrantc>
beeble: so, it's not clear to me what you mean by splitting out the bl31.bin from the m0.bin ... as upstream arm-trusted-firmware builds two separate files, only the bl31.bin has the 4GB size issue ...
<LongWork>
yeah although usually you create the texture specifying a format
<vagrantc>
beeble: i recognize that you're making a FIT image to dump onto boot media
<LongWork>
dmabuf import with drm format is a bit specific, as it asks for an input format, but will create an output format that is determined with driver and not by what you would pass to the functions
<LongWork>
as i said vaapi would take two planes as well for like Y and then UV, and would output an NV12 texture
<LongWork>
so RGBA is not something mandatory... just a bit retarded that you can't query that from the EGLImage or something
<phh>
vaapi is not gles, you don't write shaders in vaapi
aalm has quit [Ping timeout: 240 seconds]
<LongWork>
well the va_egl renderer uses egl to create textures as well
<LongWork>
same API, different DRM input formats, and different output texture format
<phh>
but does OpenGL knows that the input is Y + UV in the vaapi case?
<vagrantc>
beeble: what exactly do you use to generate the bl31.bin?
<LongWork>
phh yes
<phh>
or it's just texture being bound and he doesn't know what he is doing
<LongWork>
you have one playne with DRM_FORMAT_R8 that's Y, and another plane with DRM_FORMAT_R8G8 that's YUV
<LongWork>
when you give that to eglCreateImageKHR, it will output an NV12 texture
<beeble>
vagrantc: upstream bl31.bin contains the atf _and_ the m0 firmware. as defined by the memory layout
<beeble>
vagrantc: what we have done is to take the m0 stuff and removed it from the atf and building it standalone
<beeble>
vagrantc: also the atf standalone without the m0 stuff
<beeble>
vagrantc: so we only get .bin files for atf and the m0, so we can load it with the spl
<vagrantc>
beeble: and upstream arm-trusted-firmware includes a bl31.bin which has atf roughly at the beginning and m0.bin somewhere near the end of the image, with a bunch of padding all around?
<beeble>
vagrantc: right. as describes in the linker script
<vagrantc>
i'm admittedly a little in over my head on some of this
<phh>
LongWork: the difference with vaapi, is that at no point EGL knows what is the texture we give it, it's just some stupid array, hence the shaders will decide what it outputs
<wzyy2>
I think it create an NV12 image
<phh>
it could create an nv12 image, if it detects the shader is trivial, but that's just optimisation. the shader itself will manipulate rgba data
afaerber has quit [Quit: Leaving]
<phh>
wzyy2: do you think rockchip will publish android sdk as you do linux sdk?
<phh>
I mean, it's already half published with firefly release...
<wzyy2>
No.. They don't have that motivation...
<Esmil>
wzyy2: oh hey. you're the Jacob Chen I wrote earlier about the rockchip-rga v10 right?
<beeble>
vagrantc: it's quite easy. if you want to use spl and not miniloader you have to use our fork at the moment :)
<Esmil>
wzyy2: cool. I've built and booted a kernel with v11 on my Chromebook Plus. is there an easy way to test that it your code actually works?
<vagrantc>
beeble: yes, that's what i want to be able to do... and for experimentation, it's probably fine. for uploading to debian, using a fork or patching upstream is less desirable
<vagrantc>
beeble: though if the patchsets are reasonbly smallish, maybe that would be the route to take
<beeble>
vagrantc: it's not really a patchset you would like to manage with quilt as it forks into two project. someone would have to rewrite everything
<beeble>
vagrantc: maybe we will find a solution with rockchip. an issue is that they already have the current solution established and having something backwards compatible will be a bit of challenge
<beeble>
something everyone is satisfied with
<wzyy2>
LongWork: I might also be possible to import Y + UV image separately on rockchip platform, though "fourcc_code('A', 'R', '1', '2')" in my commit is wrong and i didn't find an appropriate replacement on libmali.
<wzyy2>
It
<wzyy2>
Doesn't intel GLES library support import DRM_FORMAT_NV12?
<vagrantc>
beeble: so, the m0.bin produced by upstream arm-trusted-firmware doesn't work for that part?
<vagrantc>
beeble: is it not possible to build the two .bin files out of the same repository?
<vagrantc>
could you build a different target with some flag, or an alternate build (e.g. plat/rk3399-split/)
<wzyy2>
LongWork: if texture_target is GL_TEXTURE_EXTERNAL_OES, then `samplerExternalOES` in shader will be RGBA, i think it's suitable for both mali and intel.
<wzyy2>
I have look the Kodi code and found it didn't use GL_TEXTURE_EXTERNAL_OES, it just use GL_TEXTURE_2D with their own YUV2RGB shader.
<beeble>
vagrantc: it is, but it does not fit the current atf build infrastructure, thats all
<mmind00>
micken: nope, no clue ... thankfully other people did the dw-hdmi driver in the linux kernel :)
<vagrantc>
beeble: hmmm... will need to figure this out if i'm ever going to have rk3399 u-boot targets working in debian
<beeble>
vagrantc: maybe ask kever what his plans are fore firefly
<beeble>
otherwise i can offer you a development board that is working :)
<vagrantc>
beeble: i could probably make use of another board :)
* vagrantc
is trying to get an armhf build farm for reproducible builds running about half arm64 boards
gnufan has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 248 seconds]
<longchair_>
Wzyy2: check Mpv hwdec_vaegl.c
JohnDoe9 has joined #linux-rockchip
<longchair_>
They seem to use that and it doesn’t output rgba it seems
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]