<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]
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
<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.
<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>
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)
<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)
<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]