02:42
<
mijk >
what do I need to download from the git in order to not have a 150MB kernel?
02:42
<
mijk >
I've built a kernel dts already
02:54
cnxsoft has joined #linux-rockchip
04:25
cnxsoft has quit [Read error: Connection reset by peer]
04:34
cnxsoft has joined #linux-rockchip
05:03
cnxsoft has quit [Remote host closed the connection]
05:09
cnxsoft has joined #linux-rockchip
06:46
cnxsoft1 has joined #linux-rockchip
06:46
cnxsoft has quit [Ping timeout: 248 seconds]
06:46
cnxsoft1 is now known as cnxsoft
07:14
cnxsoft has quit [Read error: Connection reset by peer]
07:15
cnxsoft has joined #linux-rockchip
07:57
<
ayaka >
I give up to make the xserver and mali work on the latest kernel
07:58
<
ayaka >
it is not necessary for video decoder
08:33
paulk-collins has joined #linux-rockchip
09:24
<
ayaka >
what the f*ck with the firefly, I can made none of video output work even at kernel 4.4
09:37
Aussie_matt has quit [Remote host closed the connection]
10:25
JohnDoe_71Rus has joined #linux-rockchip
12:43
<
phh >
ayaka: X11 mali r12p0 works for me on 4.10-rc
12:44
<
ayaka >
phh, it seems that it is a problem with firefly reload board
12:44
<
ayaka >
not with kernel
12:45
<
ayaka >
maybe I would have a try on miniarm on the weekday
12:45
<
ayaka >
and firefly release
12:45
<
phh >
what's miniarm btw? I've seen it a lot referenced, but I just found one ref on aliexpress
12:46
<
ayaka >
I have finally understand the last piece of H264, and ready to write a new decoder
12:46
<
phh >
517 is EDEFERED no?
12:46
<
ayaka >
phh, it is made by ASUS
12:46
<
phh >
oh it's the dev board by asus?
12:46
<
ayaka >
and I don't know when it would be on sale, but it has been published at CET
12:47
<
phh >
yup yup I see, I just didn't know it was named miniarm
12:47
<
ayaka >
phh, I may check your kernel later
12:47
<
phh >
ayaka: fyi, concerning my mainline exploration, i've found that an h265 file properly decodes with gstreamer/mpp
12:47
<
phh >
only h264 fail
12:48
<
phh >
in kernel logs I get
12:48
<
phh >
rk-vcodec ff9a0000.vpu-service: can not find 43 buffer in list
12:50
<
ayaka >
phh, it is normal for the new buffer importing
12:50
<
ayaka >
phh, have you tried chmod 666 /dev/vpu-service
12:50
<
phh >
I run it as sudo -_-'
12:51
<
ayaka >
phh, any logs from mpp or gstreamer?
12:51
<
phh >
i didn't get them yet, sec
12:52
<
phh >
(I'm still having the stupid mmc bug at boot which makes my testing much slower...)
12:54
<
phh >
mpp_buf_slot: mpp_slots_set_prop found invalid input slots 0xb4816cc0 type 3 val (nil)
12:55
<
ayaka >
with --gst-debug=vpudec:5 and pipeline
12:57
<
phh >
filesrc location=2.mp4 ! qtdemux ! queue ! h264parse ! vpudec ! kmssink
12:57
<
phh >
that's the pipeline
12:58
<
phh >
and then kernel panic
12:59
<
phh >
well, first many iommu faults
12:59
<
ayaka >
phh, it looks like a few frame have been decoded
12:59
<
phh >
yup, I do see some frames
12:59
<
ayaka >
but failed in the middle
13:00
<
ayaka >
phh, in my memory, the upstream rockchip drm still use gem
13:00
<
ayaka >
maybe you can't allocate enough frames from kernel
13:01
<
phh >
.driver_features = DRIVER_MODESET | DRIVER_GEM |
13:01
<
phh >
DRIVER_PRIME | DRIVER_ATOMIC,
13:01
<
phh >
I assume this means it uses indeed GEM?
13:01
<
ayaka >
I forget, recently I am little busy, I don't look at kernel recently
13:02
<
ayaka >
we change to use iommu just a month ago to solve the buffer allocation problem
13:04
<
phh >
does it make sense for all h264 to fail but for h265 to success, or should I try to narrow down working and failing files? or does it seem totally unrelated?
13:05
<
ayaka >
not sure, it depends on the video source
13:06
<
phh >
my h264 video source is youtube at the moment
13:06
<
phh >
I'm going to try some other
13:06
<
ayaka >
maybe your hevc video source doesn't use lots of reference frame
13:06
<
ayaka >
but usually not
13:06
<
ayaka >
enanble the debug for vpubufferpool as well please
13:07
paulk-collins has quit [Remote host closed the connection]
13:09
<
phh >
uh... now it works ?!?
13:10
<
ayaka >
speed problem?
13:10
<
ayaka >
enable more long means more slow
13:22
<
ayaka >
phh, btw, which board do you use?
13:23
<
ayaka >
chromebook, I see
13:35
paulk-collins has joined #linux-rockchip
13:51
cnxsoft has quit [Quit: cnxsoft]
14:51
kkkio has joined #linux-rockchip
14:52
kkkio has quit [Client Quit]
15:34
paulk-collins has quit [Ping timeout: 240 seconds]
15:49
paulk-collins has joined #linux-rockchip
16:05
mrjay has joined #linux-rockchip
16:07
mrjay has quit [Client Quit]
16:35
scelestic has quit [Read error: Connection reset by peer]
16:46
paulk-collins has quit [Ping timeout: 240 seconds]
16:48
scelestic has joined #linux-rockchip
17:12
paulk-collins has joined #linux-rockchip
17:25
vagrantc has joined #linux-rockchip
17:25
vagrantc has quit [Changing host]
17:25
vagrantc has joined #linux-rockchip
18:35
mrjay has joined #linux-rockchip
18:37
mrjay has quit [Client Quit]
20:42
<
mijk >
what do I need to download from the git in order to not have a 150MB kernel? I have the kernel dts already
21:10
<
phh >
I don't really understand how you could get a 150MB kernel...
21:10
<
phh >
unless you took vmlinuz instead of zImage that is
21:40
wzyy2 has quit [Ping timeout: 260 seconds]
22:25
<
mijk >
yeah, I didn't find zimage
22:42
<
mijk >
I built from the root of the git
22:43
nighty has quit [Quit: Disappears in a puff of smoke]
22:55
paulk-collins has quit [Quit: Leaving]