ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
chen_ has joined #linux-rockchip
aalm has joined #linux-rockchip
muvlon has joined #linux-rockchip
<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
<vagrantc> so, does this mean the upstream arm-trusted-firmware isn't really useable for rockchip platforms?
<vagrantc> (presuming that's upstream ^^)
<beeble> haven't yet looked at the rk3328 atf
<vagrantc> rk3399 just fails to build, due to m0 not finding arm-none-eabi-gcc ... despite having it installed
<beeble> will do it later today
<vagrantc> thanks
<vagrantc> oh, wonder if this is a gcc-7 issue...
* vagrantc considers gcc-6
chen_ is now known as wzyy2
<wzyy2> got one
<wzyy2> it's kind of small
<wzyy2> seems better than firefly ; )
<vagrantc> beeble: interesting, building a native build rather than cross-compiling worked
<vagrantc> beeble: even with the m0 ...
<vagrantc> course, it's still got the bizarre 4GB issue
<wzyy2>, maybe you could try this ATF .
<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> vagrantc: see;a=blob;f=board/theobroma-systems/puma_rk3399/fit_spl_atf.its
<beeble> thats why we decoupled the parts
<vagrantc> that actually points to one of the goals here; to build u-boot targets in debian that require ATF
<vagrantc> namely, firefly-rk3399
<vagrantc> and others, too, eventually
<vagrantc> so, the package builds natively... or at least seems to
<beeble> haven't tried it for a while. but a few weeks ago i was definitly able to crossbuild it
<vagrantc> wzyy2: thanks!
<vagrantc> wzyy2: that pretty much seems exactly the issue...
* vagrantc wonders how to transfor the .elf into a .bin
lurchi_ has quit [Ping timeout: 255 seconds]
<wzyy2> = = maybe`dd if=bl31.bin of=bl31-rk3399.bin size=xxx`?...
muvlon has quit [Quit: Leaving]
<vagrantc> figured out my cross-compiling issue ... it was installing the arm64 gcc-arm-none-eabi ...
<vagrantc> wzyy2: what's the magic number for xxx ?
<vagrantc> :)
* vagrantc wonders if that would work
<wzyy2> ‎beeble‎, according to this readme:;a=blob;f=board/theobroma-systems/puma_rk3399/README;h=f67dfb451ffd36745a5209a83459a8337134b75d;hb=HEAD
<wzyy2> Do you have some changes for ATF to build standalone bl31?
<vagrantc> according to i guess i could truncate it at 4MB
<vagrantc> which is overkill, but would make the package useable... maybe
<beeble> wzyy2: yes, we splittes the m0 firmware out. to generate a standalone binary we can load with u-boot
<beeble> having the pmu firmware in the atf repo is somewhat discussable anyway
<beeble> but the main reason is that spl just can't handle it at the moment and probably not in the near future
<vagrantc> well, i've managed to truncate the bl31.bin files down to 4mb ... no idea if they have the right 4MB :)
_whitelogger has joined #linux-rockchip
<vagrantc> well, will have to wait till another day to test
* vagrantc waves
vagrantc has quit [Quit: leaving]
vstehle has joined #linux-rockchip
<wzyy2> It look like the sections "text_sram, data_sram" are also dropped, but i didn't find this part in fit_spl_atf.its.
<beeble> wzyy2: i assume they are part of the cortex-m0 firmware linker script. the fit image only knows the load address and entry point.
<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
<beeble> last discussion about it i find in my inbox is
<beeble> but there could be talk off-list i'm not aware of
descend-irc has joined #linux-rockchip
longchair_ has joined #linux-rockchip
Ke has quit [Read error: Connection reset by peer]
Ke has joined #linux-rockchip
Ke has joined #linux-rockchip
wadim_ has joined #linux-rockchip
amstan has quit [Ping timeout: 255 seconds]
amstan has joined #linux-rockchip
nasuga has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 248 seconds]
LargePrime has joined #linux-rockchip
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
kaspter has joined #linux-rockchip
kaspter has quit [Ping timeout: 255 seconds]
kaspter has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-rockchip
<wzyy2> oops, 96board don't have ethernet jack.... lose interest : /
amstan has quit [Ping timeout: 260 seconds]
amstan_ has joined #linux-rockchip
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
<phh> I still don't understand why you need it...
nasuga has joined #linux-rockchip
<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
<vagrantc> apparently, the issue is already noted here:
<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
<beeble> vagrantc: brb, have to check something
<phh> LongWork: "A shader that uses external texture samplers
<phh> conversion from YUV to RGB"
<phh> may require some number of hidden uniform variables to implement the
<phh> "If the source image is stored in YUV
<phh> (or some other basis) then the YUV values will be transformed to RGB
<phh> values."
chen_ is now known as wzyy2
<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 :)
<wzyy2> yes
<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
aalm has joined #linux-rockchip
<wzyy2> Esmil, if you could use this plugin
<wzyy2> you could use this plugin
<Esmil> i'll try that, thanks
<wzyy2> Or you could run this demo(some API might be out-of-dated)
<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?
afaerber has joined #linux-rockchip
aalm has quit [Ping timeout: 258 seconds]
<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]
muvlon has joined #linux-rockchip
thomas75 has joined #linux-rockchip
<thomas75> Hi, anyone able to boot RK3188 via SD card ? Following the readme here section "Booting from an SD card on RK3188"
<thomas75> I have configured buildroot 2016.08.x
<thomas75> getting uboot, kernel and rootfs
<micken> mmind00: OK , sad , getting frustrated :)
<thomas75> I have the CS918 Q7 media player
leah2 has quit [Ping timeout: 240 seconds]
JohnDoe9 has quit [Quit: KVIrc 4.9.2 Aria]
<thomas75> Nobody online can help ?
VargaD has joined #linux-rockchip
thomas75 has quit [Quit: - A hand crafted IRC client]
<micken> thomas75: is the mediaplayer
<micken> well
thomas75 has joined #linux-rockchip
<micken> thomas75: Does the mediaplayer boot from sd?
<micken> I mean is the board inside configured for it?
<thomas75> Yes,
<thomas75> Yes it is
<thomas75> I got an old linux image working
<micken> ok
<thomas75> (found on the net)
<micken> I guess you have a serial connection to it?
<thomas75> MMh ... no, just looking at the output on HDMI and the LED on the device
<thomas75> HDMI is activated in the kernel
<thomas75> I should see something
<micken> Is the u-boot configured, its variables to boot the kernel?
<thomas75> Yes, u-boot is configured with defconfig rockchip, I didn't change anything
<thomas75> CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled
<thomas75> didn't change any address
<micken> That doesn't give you the kernel boot information into u-boot
<micken> afaik
<beeble> distroboot should be default on afaik
<micken> ok
<thomas75> My U-Boot config:
<beeble> so a boot.scr or something similar in your /boot should be read
leah2 has joined #linux-rockchip
<micken> folow beebles advice and look for a boot.scr in /boot
<micken> If I remember it right , there is also possible to add/change default environment for u-boot at build time
thomas75 has quit [Quit: - A hand crafted IRC client]
thomas75 has joined #linux-rockchip
<thomas75> I'm following instructions here:
<thomas75> For armv7 with SPL with SPL_BACK_TO_BROM option enabled(rk3036, rk3188, rk3288):
<thomas75> dd if=idbloader.img of=sdb seek=64
<thomas75> dd if=boot.img of=sdb seek=32768
<thomas75> dd if=rootfs.img of=sdb seek=262144
<thomas75> where idbloader has been generated with info here:
<thomas75> boot.img is a FAT partition with the kernel DTB and Extlinux
<thomas75> and rootfs comes directly from buildroot process (rootfs.ext4)
<beeble> Note, when using boot from SD card, need to update the kernel cmdline(which is in extlinux.conf) for the correct root value.
<beeble> did you do that?
<beeble> or check your buildroot rootfs for such a file
<thomas75> Yes, I did:
<thomas75> label rockchip-kernel-4.4
<thomas75> kernel /zImage
<thomas75> fdt /rk3188-radxarock.dtb
<thomas75> append earlycon=uart8250,mmio,0xff1a0000 root=/dev/mmcblk0p2 rootwait rootfstype=ext4 init=/sbin/init
<beeble> hopefully it will set correct values
<thomas75> label rockchip-kernel-4.4
<thomas75> kernel /zImage
<thomas75> append earlycon=uart8250,mmio,0xff1a0000 root=/dev/mmcblk0p2 rootwait rootfstype=ext4 init=/sbin/init
<thomas75> fdt /rk3188-radxarock.dtb
<thomas75> the root is the second partition
<thomas75> may be the problem is on dtb ....
<thomas75> I don't know DTB very well and used one from a board that uses the same RK3188
<beeble> that could go wrong. the dtb describes pretty much everything of the actual hardware
<thomas75> Yeah ....
<thomas75> also have another question about the dd tool:
<thomas75> dd writes block, but what about the partition table ? MBR or GPT ?
<beeble> without a serial connection it will be hard do debug
<thomas75> Yes you're right, I need to open the board
thomas75 has quit [Quit: - A hand crafted IRC client]
thomas75 has joined #linux-rockchip
thomas75 has quit [Client Quit]
VargaD has quit [Ping timeout: 258 seconds]
VargaD has joined #linux-rockchip
<xevious> Has anyone else seen distorted (pink and blocky) video with RK3328?
<xevious> Hm. X seems to crash as soon as something attempts to use GL.
aalm has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
lkcl has joined #linux-rockchip
gnufan has quit [Quit: Leaving.]