ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
lurchi_ is now known as lurchi__
lkcl has joined #linux-rockchip
nasuga has quit [Ping timeout: 246 seconds]
aalm has quit [Quit: xyz 1.9]
aalm has joined #linux-rockchip
nasuga has joined #linux-rockchip
pfeerick has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-rockchip
pfeerick has joined #linux-rockchip
BV1AL has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-rockchip
vstehle has quit [Ping timeout: 248 seconds]
naobsd has quit [Ping timeout: 264 seconds]
ventosus has quit [Ping timeout: 264 seconds]
naobsd has joined #linux-rockchip
ventosus has joined #linux-rockchip
zzarr has quit [Ping timeout: 240 seconds]
cyteen has quit [Ping timeout: 240 seconds]
zzarr has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 260 seconds]
vstehle has joined #linux-rockchip
nasuga has quit [Ping timeout: 240 seconds]
Ke has quit [Quit: leaving]
cyteen has joined #linux-rockchip
ayaka has quit [Ping timeout: 255 seconds]
gnufan has joined #linux-rockchip
kloczek has joined #linux-rockchip
ayaka has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
<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> is it actually just about adding the USB-id or is there something non-trivial involved?
<jkarlson> is it safeish to just try it out?
Ke has joined #linux-rockchip
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;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
<Ke> notably rockchip has a for rkflashtool that has rk3399 USBid =D
<Ke> damn this is a mess
mrueg has quit [Remote host closed the connection]
indy has quit [Ping timeout: 240 seconds]
<Ke> apparently rkflashtool is expected to work...
<Ke> git diff between the rockchip repo and community repo shows just some silly scripts and the USB ids
indy has joined #linux-rockchip
mrueg has joined #linux-rockchip
gnufan has joined #linux-rockchip
<mmind00> Ke: also ... which is upgrade_tool variant with sources
<mmind00> is "a" upgrade_tool variant
<Ke> yes, that is the one I am diffing
<Ke> seems to only have the scripts I mentioned and USBid changes
<Ke> mmind00: would you have any idea, is there some variant that is known to work, or is my board just broken
<mmind00> Ke: I've written uboots with it ... but I don't touch Rockchip userspaces at all, so can only say for uboot for sure
<Ke> you have flashed u-boots over usb to a device that is running in the recovery mode?
<Ke> or flashed u-boots from u-boot already running on the device?
descend-irc has quit [Quit: Connection closed for inactivity]
<Ke> oh sorry, nvm I missread rkdeveloptool as rkflashtool
<Ke> I noticed that rockchip repos also have that with minor changes
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<beeble> Ke: the bootorder is fixed. the bootrom will check spi, emmc, sd card and if no magic found start the usbloader
<beeble> Ke: rkdeveloptool works fine with "maskrom" to write on emmc
<Ke> beeble: thanks for the exchaustive reply
<Ke> beeble: so if I had a bootloader on spi flash that would be loaded but would be defunc, my device would actually be bricked?
<beeble> i haven't tested it in any other way then maskrom
<Ke> obviously I could flash the spi externally or something...
<beeble> yes, you would have to prevent loading the broken bootloader. for example keeping the spi clock line low
<beeble> same for emmc
<Ke> well I can force the revocery mode using buttons, but if that only allows me to flash emmc, it's no good for fixing the spi flash
<Ke> I had to modify the source to make rkdeveloptool to make it compile, wonder, if rockchip accepts patches
<beeble> does the firefly even has a spi nor as bootsource?
<Ke> so they say, though nand
<Ke> seems to work, thanks everyone for help
<beeble> i don't see a nor flash in the schematics
<Ke> hmm, but you agree that the page says there is?
<Ke> well perhaps I am just reading between the lines
<Ke> emmc is good enough for me
<beeble> yes but the page is talking about the rk3399 in general
<Ke> besides, when it's talking about rk3288 =o)
<Ke> which is probably a typo
<Ke> I would love to be able to cleanup all the mess while passing through
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #linux-rockchip
phinxy has joined #linux-rockchip
phinxy has left #linux-rockchip [#linux-rockchip]
<Ke> does upstream u-boot support rk3399 raminit?
lurchi_ is now known as lurchi__
<mmind00> Ke: yes, though I only get 2GB on the firefly right now, as the uboot ram-driver doesn't handle the dual-rank chips on the firefly so far
gnufan has quit [Ping timeout: 240 seconds]
lurchi__ is now known as lurchi_
<Ke> thanks
<Ke> so I guess I'll use the firefly variant
gnufan has joined #linux-rockchip
lurchi_ is now known as lurchi__
JohnDoe7 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
aalm has quit [Ping timeout: 264 seconds]
_whitelogger has joined #linux-rockchip
LargePrime has quit [Remote host closed the connection]
nasuga has joined #linux-rockchip
Myy has joined #linux-rockchip
JohnDoe7 has quit [Quit: KVIrc 4.9.2 Aria]
<Myy> Meow
<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 ... ?
<phh> not public
<Myy> Just have to wait a bit then
<phh> I hope they'll publish it :s
<Myy> If that wasn't for the veryLongNamesForFunctionPointersAndStuffLikeThatKHR, this example would be easy to read
<phh> you forgot the vk prefix :P
<Myy> vkMakeMeASandwichButDontPutPicklesBecauseIDontLikePicklesKHR*
<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> SDK being the ARM meaning of SDK
<Myy> "Here's some samples, play with it"
gnufan has joined #linux-rockchip
<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
kloczek has joined #linux-rockchip
<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 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.
<phh> mmm there is though it says mali-400
<Myy> Well, the driver for the Midgard was supposed to be "TAMIL"
<Myy> But the main developer refused to provide the sources, officially, because people might "criticize his code".
akaizen has quit [Excess Flood]
akaizen has joined #linux-rockchip
<Myy> Tamil being also a language, searching for it on Github is... time consuming
<Myy> Some people are hard at work :
<cyrozap> Myy: I wouldn't call that "hard at work" :P
<cyrozap> Myy: You might be more interested in this (not my project):
<Myy> Nice !
<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 : 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.
aalm has joined #linux-rockchip
<Myy> [ 457.460489] rk_iommu ff9c0440.iommu: iova = 0xff9d8800: dte_index: 0x3fe pte_index: 0x1d8 page_offset: 0x800
<Myy> [ 457.471471] rk_iommu ff9c0440.iommu: mmu_dte_addr: 0x00000000 dte@0x00000ff8: 0x000000 valid: 0 pte@0x00000000: 0x000000 valid: 0 page@0x00000000 flags: 0x0
<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 :-) ....
cyteen has quit [Ping timeout: 248 seconds]
cyteen has joined #linux-rockchip