ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
vagrantc has quit [Quit: leaving]
nighty has joined #linux-rockchip
athidhep has quit [Quit: athidhep]
_whitelogger has joined #linux-rockchip
nighty- has quit [Remote host closed the connection]
nighty- has joined #linux-rockchip
lkcl has joined #linux-rockchip
muvlon_ has quit [Remote host closed the connection]
beeno has joined #linux-rockchip
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-rockchip
<LongChair> anyone knows when stdint is supposed to be back ? :)
cnxsoft has joined #linux-rockchip
<LongChair> @phh : vpu will output NV12 frames for 8 bits format, what about for 10 bits HEVC, any idea on what it is supplying
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 264 seconds]
cnxsoft1 is now known as cnxsoft
<LongChair> most likely P010LE
wzyy2 has joined #linux-rockchip
<wzyy2> we return to work on 2.05
beeno has quit [Quit: Page closed]
Omegamoon has joined #linux-rockchip
ssvb has quit [Read error: Connection reset by peer]
LongWork has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
<dlezcano> mmind00, hi Heiko
<mmind00> dlezcano: Hi
<dlezcano> mmind00, it is not clear for me what clock provides the rockchip timer
<dlezcano> mmind00, xin24m or cru ?
<dlezcano> mmind00, I'm wondering if we have to necessarily enable prepare both
<mmind00> nope, xin24m is the core oscillator which supplies the clock controller (cru) ... this in turn normally has a gate-clock for each timer ip
<mmind00> dlezcano: ^ ... and the sclk_timerX are just that, gating the flow of xin24m to each timer block
<dlezcano> hmm, so the description in the dt is wrong, no ?
<dlezcano> timer: timer@ff810000 {
<dlezcano> compatible = "rockchip,rk3288-timer";
<dlezcano> clocks = <&xin24m>, <&cru PCLK_TIMER>;
<dlezcano> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
<dlezcano> reg = <0xff810000 0x20>;
<dlezcano> clock-names = "timer", "pclk";
<dlezcano> };
<mmind00> dlezcano: not necessarily :-) ... i.e. I was looking at the rk3188 right now, it _may_ not be similar on the rk3288
<dlezcano> this description is from rk3288.dtsi
<mmind00> dlezcano: just writing down findings ... that timer is channel 0 of the 2ch timer block, the rk3288-cru only has gated clocks for the other timer block ... still going deeper
<dlezcano> So as xin24m is not providing the timer, this description is wrong
<mmind00> dlezcano: I still don't follow ... in your snippet above it does reference xin24m, which looks correct for that specific timer
<mmind00> dlezcano: and yep, looking at the TRM, the two timers in the alive subsystem (this one and another one) don't have gateable clocks, so it seems to directly come from xin24m
<mmind00> where the rk3188 does have gates for all timer clocks
<dlezcano> mmind00, actually I'm looking if the double enable-prepare is needed for the clocks.
<dlezcano> Alexander's patches introduce the clocksource using this IP
<dlezcano> with two different init paths
<dlezcano> one for the clockevent
<dlezcano> and one for the clocksource
<dlezcano> but both share a common init code where those two clocks are initialzed
<dlezcano> which make a bit of code duplication
<dlezcano> So I'm checking if get-enable-prepare is really necessary for 'timer' and 'pclk'
<dlezcano> So if I follow, xin24m is the main oscillator, so it should be in any case enabled-prepared
<dlezcano> maybe we can skip this step in the timer driver, no ?
<mmind00> dlezcano: I would think so ... the rockchip timer blocks always have 2 supplying clocks ... timer as the actual timer-clock and pclk for the timer-control
<mmind00> dlezcano: wouldn't think so
<mmind00> on the rk3188 all the timer supply-clocks are gateable, so _need_ to be enabled
<mmind00> dlezcano: only the alive-timers on rk3288 have that exception of not being gateable, the devicetree is meant as describing the hardware and each timer really has these 2 clocks
<dlezcano> mmind00, ok, that is clear. Thanks.
wzyy2 has quit [Ping timeout: 255 seconds]
wzyy2 has joined #linux-rockchip
beeno has joined #linux-rockchip
lkcl has quit [Ping timeout: 252 seconds]
lkcl has joined #linux-rockchip
Myy has joined #linux-rockchip
Myy has quit [Quit: Leaving]
nighty has quit [Quit: Disappears in a puff of smoke]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
paulk-collins has quit [Quit: Leaving]
lkcl has quit [Read error: Connection reset by peer]
nighty has joined #linux-rockchip
paulk-blaze has joined #linux-rockchip
robogoat has quit [Ping timeout: 240 seconds]
mac-l1 has joined #linux-rockchip
robogoat has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
paulk-blaze has quit [Read error: Connection reset by peer]
paulk-blaze has joined #linux-rockchip
Myy has joined #linux-rockchip
paulk-blaze has quit [Ping timeout: 240 seconds]
paulk-blaze has joined #linux-rockchip
<beeno> hello Myy
<Myy> Hello beeno
<beeno> hope you're well. I've got that MiQi booting up on the ugoos, but only on the EMMC
<Myy> That's a good start !
<beeno> I don't see any kind of mali gpu libs, those not coming with the software?
<Myy> In the MiQi Debian images ? There might not be there, yeah. You might need to install them from rockchip-linux repositories
<beeno> anyway I'm not too worried about that just yet. What I'd like to achieve is running it from the microSD instead. Have you ever done that?
<beeno> The xubuntu from ugoos does do that but it's really old
<Myy> I have not tried it, no. I do not have any microSD at the moment.
<beeno> but your board has the port?
<Myy> Yup
<beeno> ok so I have another thing that bugs me. Having booted from the SD, I can't seem to access a boot partition
<Myy> IMHO, booting from the microSD should require a combination of U-Boot configuration and configuring the "root=/dev/xxx" correctly
<Myy> in the extlinux.conf file
<beeno> I'd like to export the device tree so I can try to use it with that rockchip linux. (pretending to know what I'm doing)
<Myy> That should not be too difficult
<Myy> Just locate the DTB file in the /boot partition
<beeno> ok so about the extlinux.config, I did see that in the build script. On this ugoos SD, there's 2 partitions, and the first is not readable, while the second contains root
<Myy> Install it on the eMMC, boot it, mount the /boot partition correctly, copy all boot files (with something like SCP) on the host computer and then on the SDCard
<beeno> so seems they've managed to write the data into that first 40mb, but without allocating usual paritions
paulk-blaze has quit [Quit: Leaving]
<Myy> That's entirely possible. You could try to extract the first 40 mb in a file and analyse the content with an hexadecimal editor
<beeno> the initial loader that starts at sector 64, how does that get configured?
<Myy> I don't have much knowledge in Rockchip's boot procedure and configuration. I just happen to flash the right images, mount the eMMC on the host computer through usb, using the "ums 0 mmc 1" command in U-Boot, create the /boot partition manually and then create the others partitions...
<Myy> However, what's the output of "ls /dev/mmc*" (ghostbin it if it's too big for IRC)
<Myy> There's some /dev/mmc?boot? partitions but they're generally not the ones containing the Linux boot files. Only the U-boot ones.
<Myy> The Linux ones might be in /dev/mmcblk?p?
<beeno> well when booting miqi off emmc, I do get the whole lot of mmcXXX
<Myy> Try to do fdisk /dev/mmcblk? and check the partition table
<beeno> shows exactly the same, only the one used for root
<Myy> and in your /boot folder, on the root partition, there's nothing ?
<beeno> so they somehow embedded boot into the initial portion of the SD and uboot somehow knows how to access that
<beeno> my root does have a boot but it's entirely empty
<Myy> By the way, yesterday Omegamoon wanted to tell you "<Omegamoon> I soldered a serial console on mine last weekend <Omegamoon> got the serial pads from here"
<beeno> yeah thanks that was still on my screen. it may be my last resort
<Myy> Well, you can try dd if=/dev/mmcblk? of=image bs=40M count=1
<beeno> what does count=1 do in this case?
<Myy> 1x40M
<Myy> If I remember correctly
<Myy> Yeah it worked
<Myy> dd if=/dev/mmcblk1 of=nya.img bs=40M count=1
<Myy> 41943040 bytes (42 MB) copied, 1.00379 s, 41.8 MB/s
<Myy> 1+0 records out
<Myy> 1+0 records in
<beeno> ok. let me peek into the boot for the miqi. there seems to be a boot0 and boo1
<Myy> You can then do "strings image" to see if there's any useful string in the copied image
<beeno> does uboot have a CMDLINE ?
<Myy> I don't think so. That's the kind of option that tend to be passed to kernels.
JohnDoe_71Rus has joined #linux-rockchip
<beeno> rootfstype=ext4 ... initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00008000@0x00002000(resource),0x00008000@0x0000A000(boot),-@x00012000(linuxroot)
<Myy> Ah, that's the rockchip configuration file
<beeno> well, I tried to do a manual build using that rockchip linux and not one of their configs used this mtdparts stuff
<beeno> i wonder if it's possible to somehow bind a filesystem to that info
<Myy> It might be possible. However, I still think that serial console access to U-Boot will make things way easier. Still, try to find the string "mmcblk" in the extracted images
<Myy> Still, a serial console access would be nice (・д・ )
<Myy> Once you have access to U-Boot, you can configure it the way you want. The other method would be to find how to create U-Boot images for Rockchip and create a U-Boot one that specifically boot the bootable partition found on the first SDCard slot.
<Myy> *specifically read the extlinux configuration from the first SDCard slot and use it to boot a kernel from the SDCard
<Omegamoon> @beeno: not sure what you're trying to run on Ugoos UT3S, but I could give it a try and see what the serial console says on mine if you want
<beeno> Omegamoon, I have this ugoos image that runs of SD. I'm trying to get to the dtb to try and export it. I want to see how to modify the dts that rockchip supply in their own linux. Because they only seem to provide them for a couple of hacker boards, rather than the Ugoos device
<beeno> reason is that it seems the rockchip linux is much more updated and has the mali stuff in there
<Omegamoon> okay, so you have an Ugoos image running...
<beeno> basically I want to manually build and use the linux supported build from rochckip, but make sure it's configured as per the UT3S
<beeno> I must add that my attempt at using the rockchip build for the rk3288evb did not start. I believe it's got something todo with the device path of the SD vs EMMC
<Omegamoon> you have rkflashtool ?
<beeno> on my build system yes
<beeno> Myy, did you say earlier I can transfer the eMMC to the SD?
<Myy> Well, technically you can, yeah. But it was more : copy the boot files from the eMMC on the SD. I thought that you could access those files easily, though.
<beeno> Omegamoon, what os are you using on your UT3s?
<Myy> However, you could give it a try with a MiQi or Firefly DTB and see how it fares.
<Omegamoon> beeno: trying to get LibreELEC working
<Myy> Worst case, some things might be off but you could always reedit the DTB files afterward.
<Myy> Here some files you could try. Didn't try them on Ugoos systems though :
<beeno> well my concern is that this device has a built in fan, and I can't imagine using the MiQi or some other random dtb is going to have that working
<Myy> Oh. Well, you can always see if it boots for one minute. Then you'll just have to find the fan address and configure it in the DTB.
<Myy> Also if you have a working Ugoos system, you could always search for 'fan' in /sys
<Myy> And figure out its address
<Omegamoon> beeno: use rkflashtool to retrieve the parameters from the (working) Ugoos image... having that, retrieve the resource.img, using rkflashtool again... from the resource.img you can extract the .dtb, which can then be converted into a .dts
<Omegamoon> if that is what you want :)
<Omegamoon> I did the same using an (Android 5.1) stock Ugoos image
<Omegamoon> for the fan, it has:
<Omegamoon> ug_fan@fff16000 {
<Omegamoon> fan-on-temp = <0x46>;
<Omegamoon> fan-mode = <0x2>;
<Omegamoon> fan-gpio = <0x3 0x9 0x0>;
<Omegamoon> compatible = "ug_fan";
<Omegamoon> reg = <0xfff16000 0x10>;
<Omegamoon> fan-off-temp = <0x41>;
<Omegamoon> };
<beeno> so you say the resource.img actually contains the dtb
<Omegamoon> yes
<Omegamoon> to unpack the resource.img use: resource_tool --verbose --unpack
<beeno> is the dtb used by both u-boot and the kernel?
<Myy> brb
Myy has quit [Quit: Leaving]
<Omegamoon> hmm... not sure
<phh> yes
<beeno> I imagine you can't use a dtb in a later kernel?
<beeno> That ug_fan in the dts would need some kind of driver which I won't have if ugoos doesn't make the code available. seems like a pointless excercise
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-rockchip
mac-l1 has quit [Ping timeout: 260 seconds]
Myy has joined #linux-rockchip
<beeno> Myy, do you feel you have access to all the source required to build and maintain the os for the miqi?
<Myy> There's still things missing. The source code is there but it will take time before I could port anything like DRM RGA, or ensure that the VPU code works correctly.
<phh> well, rga isn't really useful, iirc both vpu and gpu can do color conversion and vop can do scaling
<Myy> I wonder if PRIME could be implemented easily. It would be nice to have the 3D and 2D chips cooperate for things like the windowing system.
<phh> yes it should be straightforward, since mapping is all done through iommu
<phh> the real difficulty is to have some code to actually use rga
<Myy> Yeah. The only code elements I've seen are some libdrm tests provided by rockchip, and some other code in the rockchip's abandoned ffmpeg tree.
<beeno> So you're saying rga is undocumented?
<phh> source code + tests is enough documented
<phh> the problem is where do you plug it? how?
<Myy> Yeah, I'm missing the big picture and, quite frankly, I don't want to write "yet another X driver".
<phh> :P
<Myy> The last big thing would be to check if the Mali Kernel driver allows you to use the processing units of the GPU easily, without "magic numbers incantations".
<Myy> And also know the Mali instructions set...
<Myy> Fortunately, the Firefly's Mali drivers have all the symbols in the driver
<phh> you want to RE mali
<phh> ?
<Myy> There's even references to C files. I wonder if there's DWARF debugging symbols too.
<beeno> as far as rga, that's a blitter isn't it?
<Myy> More like see if you can create a driver without looking at Mali source code
<phh> if you want to do that, DO NOT even try to download the mali source code
<phh> beeno: yes
<Myy> The kernel driver allows you to control the GPU memory, as some Samsung engineers provided code for On-The-Fly texture memory compression
<phh> it's not memory compression, it's memory retrieval which is possible to memory compression (for what I've understood that is)
<phh> anyway, ATSC would be really far in the todo list for a gpu driver
<Myy> So, in order, the current projects "that would be nice to do" are : VPU port - port DRM enhancements
<phh> drm enhancements of vop or rga?
<Myy> Why not both ?
<beeno> so as far as rga, I could use that. I've been doing software decoding of vp8 and converting that from yuv420p to rgba on the blit was useful in some cases.
<beeno> I think the mali on the rk3288 might be fast enough to just do it there though
<phh> Myy: well as we mentioned, rga is useless, and for vop, I don't know which improvements we're talking about
<Myy> But currently see if there's enhancements for the current DRM implementation (mostly PRIME as the ARM Mali drivers might be able to use these techs)
<phh> I'm currently trying to port android on mainline rk3288, and I see it's missing some DRM stuff
<phh> but I'm not too sure if this is a real miss
<Myy> Well, as long as things are fluid enough on the screen, I guess that's fine
<Myy> That said, do you know a nice software to draw quick schemas + free hand drawings that can be shared easily ? I've looked at Pencil but it cannot do free-hand drawing :C
<Myy> (So basically that's a Pencil that can't draw)
<phh> no clue
<Myy> So are things fluid enough on Android for RK3288 ?
<Myy> Like "no lag on the menus" or things like that
<phh> I have a tablet running android 4.4 at 1920x1200 very smoothly yes
<Myy> Can Android use mainline kernels or does it require their own version of the kernel ?
<phh> you can have a working android with mainline kernel, though I doubt full real support is possible
<Myy> beeno Well the Mali GPU is certainly very fast. And given that they support OpenGL ES 3.2, there might be a few others ways to share VPU and GPU buffers, in order to avoid copying data
<beeno> who knows. on the odroid with the mali450 you could only share using the egl image khr and that still resulted in an internal copy. they didn't have true dmabuf or similar
<beeno> i was able to achieve my goals though and that gpu is about 1/2 the speed of the T764
<beeno> so I wonder if the latest mali drivers you have for the T764 actually does support dma buf sharing or not and if that's usable with VPU
<beeno> I would actually be happy enough if I can do 4 simultaneous video decodes with the VPU to ram. Do you think that's possible?
<beeno> And I'm talking about something like 1280x720 only
<Myy> With OpenGL ES 3.0, you might be able to use glMapBuffer , disable the forced synchronisation (or use double buffering...)
<phh> Myy: well it is supposed to be capable of vulkan
<Myy> Yeah, indeed
Omegamoon has left #linux-rockchip [#linux-rockchip]
<beeno> that's what I need
<phh> it would be nice to have an opensource vulkan driver before mali ;)
<phh> (but that's quite impossible)
<Myy> (that would require the Mali instruction set)
<beeno> I'm fine with the mali provided blobs, as long as it can be used
<Myy> Hoho!
<phh> beeno: yes latest mali drivers use dma-buf
<beeno> phh: what board are you using?
<beeno> Myy: I already use that on win64 and linux x64
<beeno> it just wasn't usable on the Mali450, as it was EGL 2
<Myy> Yeah... GLES 2.x...
<beeno> I'm hoping I won't need to do much to get that to work on EGL3 as my app is originaly OpenGL
<Myy> It's funny to see how they went from "Castrated OpenGL 2" to "OpenGL 3 and OpenGL 4 functionnalities"
<beeno> not so funny if it's contributing to a lot of grey hairs
<phh> beeno: I've got many, but I'm using c201
<Myy> Indeed
<beeno> phh: ok that's quite cool because you can even use it as a dev machine for rk3288 solutions
<phh> beeno: exactly :P
<beeno> so do you run linux on it?
<phh> I still use chromeos for day-to-day
<phh> but I have a linaro/debian mainline running on sdcard
<phh> and I've started launching an android
<phh> (I have many other rk3288 devices, for which Android makes more sense)
<beeno> would you say that android has low performance overhead compared to linux on a rk3288?
afaerber has quit [Quit: Leaving]
mrjay has joined #linux-rockchip
mrjay has quit [Quit: Page closed]
mac-l1 has joined #linux-rockchip
beeno has quit [Ping timeout: 260 seconds]
<mac-l1> beeno: i have just made an ffmpeg player that decodes using vpu and uses dma_buf import to eglimage that can be used for texture rendering.
<mac-l1> just checked and it easily plays three h264 movies each in its own X11-window, using in total about 20% of the CPU power (top)
<mac-l1> on my miqi. the dma_buf import does the zero-copy thing and also takes care of the yuv420sp/nv12 to rgb conversion
<mac-l1> so an rgb shader can handle the rgb texture afterwards
<Myy> Oh, nice !
<Myy> I was wondering if there's OpenGL ES extensions that can do YUV<->RGB directly.
<mac-l1> also 4K is OK (4k-chimei-inn-60mbps) albeit a bit jerky. but i guess that my prototype player can be tuned for this.
<Myy> Profile Guided Optimisations might help on this one ?
<mac-l1> on kernel 3.14 i also used the drm rga api to do all kind of conversions. similar player but uses drm rga to blit to X11 window buffers directly so without GPU EGL/GLES, with an armsoc driver.
<mac-l1> so if needed i can see if i can still find my experimental code...
<Myy> Well, that would indeed help testing RGA implementations
<Myy> Anyway, that's it for today. See you everyone !
Myy has quit [Quit: Leaving]
<LongChair> mac-l1: i'd be interested in the 4K checks :)
<LongChair> from what i have been told Mali aint capable to output 4k@30 with gpu
<mac-l1> LongChair: i didnt check the 30fps, only 24fps (4k-chimei-inn-60mbps). the stutter comes when stream bandwidth peaks at 110-140mbps. it could be that then the gpu and vpu need too much mem access together.
<mac-l1> however, on my good old firefly on android 4.4.2 it alwayed plays this 4K perfectly smooth...
<mac-l1> also using machybris on linux (vpu and gpu (egl/gles0)
<LongChair> what i have heard is that 4K is only doable properly with drm + dmabuf
<mac-l1> LongChair: it probably depends on what 4K context (bandwidth/mbps). right now it plays the 4K movie properly 90% of the time; decoding and rendering all 4K frames nicely using VPU and GPU (with dmabuf zerocopy)
<phh> mac-l1: oh that's nice
<phh> I mean your ffplay
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria]
<phh> mac-l1: what did you use rga for?
<phh> color conversion? scaling?
<mac-l1> phh: both. it blitted the nv12 frame (eg 1080p) directly to the rgba back buffer of the X11-window (varable size)
<mac-l1> see my ffmpeg_play_rga_x11 code snippet:
<mac-l1> actually the rga2 is quite a nifty thing. however i liked the old rga2 device driver better (used in android) for its simple, powerful ease of use. so that could also be an option to incorporate in mainline.
<mac-l1> instead of incorporating it into drm.
vagrantc has joined #linux-rockchip
<phh> mac-l1: well vpu can do nv12 => rgb, and vop can do the scaling, so...
<phh> right vpu scales too
<phh> ... vop is even capable of color conversion
<phh> how many color conversion components are there in that chip?!?!
<phh> I count only 5 isp, iep, vpu, vop, rga (well I assume hevc block can do it as well)
ssvb has joined #linux-rockchip
BenG83 has joined #linux-rockchip
nighty has quit [Read error: Connection reset by peer]