<LongChair>
ayaka: it seems that MPP MPEG2 decoder cannot use full frame packets. Could you confirm if this is right and if it is different from other decoders
kloczek has quit [Ping timeout: 264 seconds]
LargePrime has quit [Ping timeout: 248 seconds]
kloczek has joined #linux-rockchip
LargePrime has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
vstehle has quit [Quit: WeeChat 1.9]
vstehle has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
kloczek has quit [Quit: kloczek]
matthias_bgg has quit [Quit: Leaving]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-rockchip
cnxsoft1 is now known as cnxsoft
kloczek has joined #linux-rockchip
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #linux-rockchip
gnufan has quit [Ping timeout: 264 seconds]
gnufan has joined #linux-rockchip
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #linux-rockchip
kloczek has quit [Quit: kloczek]
kloczek has joined #linux-rockchip
gnufan has quit [Ping timeout: 255 seconds]
gnufan has joined #linux-rockchip
gnufan has quit [Ping timeout: 260 seconds]
gnufan has joined #linux-rockchip
descend-irc has joined #linux-rockchip
jkarlson has joined #linux-rockchip
<jkarlson>
has anyone looked at supporting rk3399 with libre flashing tools
jkarlson has left #linux-rockchip [#linux-rockchip]
<Ke>
anyone playing around with firefly-rk3399 in general?
<Ke>
does anything/something work on mainline kernel and mainstream debian or similar GNU/linux
BenG83 has quit [Quit: Leaving]
kloczek has quit [Quit: kloczek]
aalm has quit [Ping timeout: 246 seconds]
cnxsoft has quit [Quit: cnxsoft]
aalm has joined #linux-rockchip
lurchi_ is now known as lurchi__
ayaka has quit [Ping timeout: 255 seconds]
ayaka has joined #linux-rockchip
<Ke>
apparently just adding usbid is not enough
<aalm>
libre flashing tools?
<Ke>
I am investigating rkflashtool
<Ke>
based on the complexity of the tool reverse-engineeting rk3399 for this could possibly not be too hard
<Ke>
rockchip provides proprietary command line tool for linux, that could be traced as well
<aalm>
oic
<Ke>
hmm, actually after failure the tool tries again, wonder what's up with that
<Ke>
I guess it could help to have another device, where it works, wonder if there is a way to boot C201 into that type of recovery mode somehow
lurchi__ is now known as lurchi_
gnufan has quit [Ping timeout: 248 seconds]
<aalm>
Ke, doesn't u-boot solve that for you?
<Ke>
sure, if you have u-boot
gnufan has joined #linux-rockchip
<aalm>
ah, so it's about initial flashing?
<Ke>
or flashing after bricking
<aalm>
was just thinking about some diffs i saw adding rockusb usb gadget support or something. was maybe in u-boot-dfu
<Ke>
also developing or hacking is much more comfortable knowing your system is unbrickable
<Ke>
perhaps, I have no idea, what is gadget, I barely know anything about USB either
<aalm>
sure, that's why i prefer booting off (micro)sd on all my boards i have.
<Ke>
yup
<aalm>
it's device mode
<Ke>
the thing is, once you get the first level bootloader on the eMMC or spi flash, you don't have to worry about touching these things at all
<aalm>
bootloaders do need updates, i have learned :P
gnufan has quit [Remote host closed the connection]
<aalm>
ke, take a look at http://git.denx.de/?p=u-boot/u-boot-dfu.git;a=blob_plain;f=doc/README.rockusb;hb=5392ac6f370398bca2cf2c4a9f38f56df40b0716
<Ke>
not very often, and you can chainload bootloader off the SD vard
<Ke>
aalm: thanks, may be relevant
<Ke>
aalm: what board are you using?
<Ke>
wonder, how can I select the bootmode in general on this firefly-rk3399, I can get to the usb flashing mode, but I have no idea, how can I select the media that first bootloader is loaded from
<Ke>
is there just static bootorder and first one with matching crc is loaded
<Myy>
Maybe I know what the "reserved_thermal" is for in the rk3288.dtsi ?
<Myy>
Is that here to cover the tsadc 0 case ?
<Myy>
I'm asking this since some software seem to rely on /sys/class/thermal/thermal_zone0/temp providing the CPU temperature, which is not the case here.
<Myy>
here being on RK3288 boards.
<mmind00>
Myy: userspace-software should never rely on hard numberings ... the tsadc on the rk3288 simply has 3 channels 0, 1 and 2 ... 0 is unsused and has nothing connected to it (hence the reserved) and 1+2 have cpu+gpu temperature readings
<Myy>
Is there a fool-proof method for getting the CPU temperature which does not rely on magic numbers ?
<phh>
Myy: hi, fyi, rockchip's android 7.1 sdk for rk3288 has vulkan support
<Myy>
Woohoo !
<Myy>
Great to hear, since I haven't tested the fbdev vulkan support and still have no time to do that in the near future.
<phh>
(I don't know if rockchip is aware of it though, I had to do symlinks myself)
<Myy>
fbdev vulkan support which only exist in one version of the Firefly RK3288 drivers provided by ARM themselves
<phh>
yup yup, I did track all people mentioning rk3288/vulkan, that's why I know you're interested :P
<Myy>
Alright :3
<Myy>
I got some documentation from ARM on how to initialize a Vulkan "framebuffer" without relying on their window API, so maybe there's a way to use these drivers on Linux... This would require a lot of work for a simple test that might not work though.
gnufan has quit [Ping timeout: 260 seconds]
<Myy>
Though, where's the rockchip android 7.1 sdk ? On their github or ... ?
<Myy>
Oh, it's Vk for variables and vk for functions
<phh>
btw do you have cool demos or actual apps or games using vulkan? :D
<phh>
I did a quick look on android, I barely found few advanced tutorials
<Myy>
Well, the ARM guys suggested me using their own Vulkan demos, which might not be *that* awesome but should provide a good overview of that the hardware can do
<phh>
I tried running the talos principle, but it requires s3tc :(
<Myy>
But beside that, I should try to write my first examples and get around it
<Myy>
Still, the Vulkan website or LunarG *might* have interesting examples. Better than a triangle with interpolated colors.
<phh>
well I think lunarg had opengl in vulkan
<phh>
which would be quite interesting
<Myy>
That might help drivers makers focusing on Vulkan only. That said, Vulkan users are generally those who feel that the hand-handling of OpenGL is impairing the performances of their hardware (for good reasons or not). :3
<phh>
hum no I'm mistaken
<phh>
well I guess that with modern mesa, just reversing-engineering vulkan should make it much easier to reverse
<Myy>
Linux/Android build:failing ... Not reassuring but... well
<phh>
android target works
<phh>
only linux/clang is broken
<Myy>
Nice !
<phh>
mmm, are artefacts available from travis
<Myy>
Well, the biggest issue with reverse-engineering closed source drivers is understanding how the shader to BLOB transformations work and how to ask the GPU to start computing and outputing and the result. Given that Vulkan provide a lot of control in this area, this sure will make things simpler.
libv_ has joined #linux-rockchip
kloczek has quit [Quit: kloczek]
<Myy>
The second biggest issue is that ARM is an IP company, so their team is mostly composed of two kind of employees : Engineers and Lawyers... Kinda hard to meddle with this stuff.
<Myy>
The LIMA driver developer was able to pull it through, though
libv has quit [Ping timeout: 260 seconds]
<phh>
well he do seem to cover his ass as much as possible
<phh>
I stubbled upon the latest mali version once, it was quite well hidden, and I couldn't find it again since then
kloczek has joined #linux-rockchip
libv has joined #linux-rockchip
<Myy>
Indeed
libv_ has quit [Ping timeout: 260 seconds]
<Myy>
Anyway, on the VPU side, big files seem to generate page faults very quickly
<phh>
high bitrate you mean?
<Myy>
Possible. My knowledge in video formats is very limited.
<Myy>
I just pull out a RAW from nyaa.si that says HEVC YUV420 and tried it.
<Myy>
I'm trying to remove the dma buffer copy and just the map the dma buffer itself, but I got a few NPE doing that. I'll have to investigate a little more.
<Myy>
I also tried to reimplement IOMMU TLB flush and...
<Myy>
It just froze the machine
<Myy>
It seems that new improvements are coming in the IOMMU DMA API, regarding automatic TLB flushes and all, so I might just wait for that to happen.
<Myy>
I see, that's how people RE closed-source drivers without reading the binary blob code.
<Myy>
Interesting
vagrantc has joined #linux-rockchip
<Myy>
Well, I've bookmarked that. I'll take a look at the code once I'm done with the VPU code.
<Myy>
Anyway, wzzy2, I've been able to remove the vcodec_*_sg functions, since they're not used anymore. I'll try to avoid the copy and then see how to flush this IOMMU, since there's no public API anymore and trying to add one like this : https://gist.github.com/Miouyouyou/3dcf5009ebce350959d30ad572ac4d26 tends to crash the SBC plain and simple. I'll get in touch with the rockchip-iommu.c developers to have some help on the subject.
<Myy>
Note that in rk_iommu_flush_tlb(session_info->dev), replacing session_info->dev by session_info->mmu_dev just spam the logs with "Can't flush nothing !". I guess I should try to attach the device before flushing it.
<Myy>
I'm pretty sure it runs out of memory, due to the flushing not working
Myy has quit [Quit: Leaving]
nasuga has quit [Ping timeout: 248 seconds]
lurchi__ is now known as lurchi_
<mmind00>
I really like playing with the lima re-start :-) ... while it cannot talk to any xservers yet, as simply a lot of stuff is still missing, I can at least render a small of-screen example on my rk3036 and rk3188 boards :-) .... https://plus.google.com/+HeikoSt%C3%BCbner_x/posts/KZsTw2HHFLm