<TomTheDragon>
Wow... nice. My rockpro64 did not work with PCIe and audio using Armbian 5.4
<TomTheDragon>
and I had some display setup issues.. but may be because I'm using a cheap chinese HDMI to VGA
<AndreVallestero>
I'm getting an ioctl segfault and vcodec / device identification errors. Not really sure what's causing it but I suspect it has somethign to do with VPU drivers.
<AndreVallestero>
There are several branches for the rk3399 since I'm not sure what's causing the errors.
<AndreVallestero>
Yeah, the VPU drivers aren't even in mainline. They're in staging.
<TomTheDragon>
ah, I see
<TomTheDragon>
yeah, it's kernel side issues
<TomTheDragon>
I'm hoping either the mainline will improve, and rockchip will rebase to a later kernel
<AndreVallestero>
Yeah, me too.
<TomTheDragon>
but not surprising... rockchip is not really targeted to mobile devices and is considered a budget processor
<AndreVallestero>
I don't even know how to verify for sure if my issues are within the VPU drivers. lsmod shows that hantro_vpu is loaded. I feel like h264 decoding would have been the first thing they had working so I'm optimistic that the issue is on my end.
<TomTheDragon>
what is your actual board?
<AndreVallestero>
Pinebook Pro
<TomTheDragon>
ah, that's definitely a different board from mine. have others gotten it working on specifically the Pinebook Pro?
<TomTheDragon>
with mainline
<AndreVallestero>
Not that I know of.
<AndreVallestero>
There are a few people trying to get it working on Armbian but as far as I know, I'm the only one working on mpp + ffmpeg on the PBP for Manjaro ARM
<hanetzer>
I wonder about that a bit. I wonder how pants it would be to port coreboot to those
<TomTheDragon>
I've found that bcm made things really easy compared to rockchip
<hanetzer>
bcm? like, broadcom?
<TomTheDragon>
yeah
<hanetzer>
fuck those guys
<TomTheDragon>
however, the rk3399 is pretty impressive compared to any of the raspberry pi SOCs
<AndreVallestero>
That's cause Broadcom used v4l2 and OMX which already has community support
<AndreVallestero>
MPP is something rockchip made for themselves, no one else uses it so it has no community other than rockchip device owners
<AndreVallestero>
I would have prefered if they used v4l2 and OMX since we would have been able to leverage alot of community knowledge and infrastructure
<TomTheDragon>
the RGA would be awesome with proper software support. it's pretty limited, but it's actually capable of 2D acceleration - a rarity for any machine with 3D
<hanetzer>
true on that front, but the state of foss for the raspi stuff's boot stack is next to nonexistant last I looked.
<TomTheDragon>
that's true
<hanetzer>
mpp at least has open code someone can use to derive a proper v4l2 setup
<TomTheDragon>
for playing 4k videos right now all I can really do is set --vf="fps=fps=15" in mpv.
<hanetzer>
aside from stuff not on the soc itself rockchip based devices have some of the best fossability of anything out there. yeah, there's some vendor shitware but its at least open shitware :P
<TomTheDragon>
yeah, that's true
<hanetzer>
like, my gru chromebook. only thing on there which is not on a fast-track to foss is the wifi
<TomTheDragon>
anyone know if there's a backport of panfrost GPU kernel-side stuff?
<hanetzer>
backport to what?
<TomTheDragon>
backport to a legacy vendor kernel
<hanetzer>
what do you need from the vendor kernel?
<hanetzer>
it may be easier to front-port that ;P
<TomTheDragon>
well, things might have improved since I tried mainline, but I had no audio and no PCIe
<TomTheDragon>
No audio is kind of problematic, and PCIe is -the- reason I picked the rockchip
<AndreVallestero>
TomTheDragon: Have you benchmarked your system with ffmpeg?
<AndreVallestero>
I'm not sure what map does but people use it for benchmarking
<urjaman>
as far as i know, the VPU doesnt have a seperate memory so saying "download" about reading it's output seems weird
<TomTheDragon>
not sure what hwdownload does, but it seems to be necessary for something
<TomTheDragon>
mpv always claims "HW-downloading" when I display to x11egl
<TomTheDragon>
maybe that is necessary for doing any manipulation on the frame, like cropping?
<TomTheDragon>
let me show an example of -f null and output to an actual video like AVI
<urjaman>
well there can be a bunch of reasons it wouldnt be able to zero-copy it...
<urjaman>
but i have no experience with the VPU so *shrug*
<urjaman>
waiting for the RK3288 patches to get to mainline :P
<hanetzer>
AndreVallestero: map maps streams to streams.
<TomTheDragon>
what's that actually mean, though
<TomTheDragon>
what if I only have a video stream and an audio stream in my input - which is my most common case
<hanetzer>
hard to explain... like, some video players (vlc), if I record game audio and mike audio as separate streams for editing purposes, it thinks of stream1 as being lang1 and stream2 as being lang2
<hanetzer>
so, ffmpeg the raw in and move the audio streams around to import both into kdenlive and cut the duplicated video stream
<PhoenixMage>
Which is what it comes up as in u-boot
<sigmaris>
I have a rockpro64 rather than a rock pi 4, and I use earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 too, which works for me...
<PhoenixMage>
Makes me think I am missing something from my kernel but I have the same issue using their kernel
<sigmaris>
I've been using mainline 5.3 and 5.4 kernels
<sigmaris>
I can't remember if having that in the DT obsoletes the console=ttyS2,1500000n8 argument or not, I have both
<sigmaris>
Also another thing I'd try is removing the earlyprintk arg, since I don't have that
<PhoenixMage>
I do have a line like that
<PhoenixMage>
ok will try that
<sigmaris>
I do remember I tried one USB-UART dongle and it couldn't really handle the 1.5Mbps baud rate that seems to be standard for rockchip stuff
<PhoenixMage>
No dice
<sigmaris>
so I switched to using the UART on a Raspberry Pi and using picocom, which works fine
<sigmaris>
hmm well short of trying other UARTs as the "client" and maybe trying picocom I'm out of ideas, sorry
<PhoenixMage>
What u-boot command should I be using for booting? booti?
<PhoenixMage>
Thanks anyway
<PhoenixMage>
Do you have CONFIG_TTY_PRINTK set in your kernel?
<sigmaris>
Nope, # CONFIG_TTY_PRINTK is not set
<sigmaris>
I just use the default command for booting in u-boot, "run distro_bootcmd"
<PhoenixMage>
thanks
<sigmaris>
afaict distro_bootcmd looks on eMMC then SD card for /boot/extlinux.conf, boot.scr.uimg, boot.scr, and EFI binaries
<sigmaris>
sorry, that should be /boot/extlinux/extlinux.conf. Anyway I put that file in place in the root partition and it reads the kernel, cmdline, initrd etc from there
<PhoenixMage>
Yeah have the same issue if I boot from there, I dont have anything but extlinux.conf in there though
<PhoenixMage>
Did you just write the idbloader.img and u-boot.itb for your u-boot?
<sigmaris>
yeah, I build u-boot and get idbloader.img and u-boot.itb, write idbloader.img to sector 64, and write u-boot.itb to sector 16384
<sigmaris>
I would try building from latest master branch of both, since I'm more confident in them working together
<PhoenixMage>
I am compiling from both latest gits
warpme_ has joined #linux-rockchip
<PhoenixMage>
Seems that commit may not have been merged though
<PhoenixMage>
into bl21
<PhoenixMage>
bl31
<PhoenixMage>
Actually I didnt pull it from github
<robmur01>
IIRC "MMC1" means eMMC, and mainline doesn't seem to like booting off that at the moment
<robmur01>
I hit the same thing on NanoPC-T4; moving everything onto SD card with "same-as-spl" boot order worked for me
<PhoenixMage>
I think its board dependent
<PhoenixMage>
I know on Rock Pi 4 mmc1 is definitely uSD
<PhoenixMage>
On my Olimex Lime2 it is emmc
matthias_bgg has quit [Quit: Leaving]
<sigmaris>
fwiw on my rockpro64, I am using eMMC, I see "Trying to boot from MMC2" from the SPL, and then u-boot proper calls the eMMC "mmc0", quite confusing
<sigmaris>
but it does boot successfully off eMMC using mainline
chewitt has quit [Quit: Zzz..]
<sigmaris>
oh and then to complete the picture, Linux calls the eMMC "mmc1"
<robmur01>
ah, right, spl_decode_boot_device() also confirms that my memory is wrong :)
<PhoenixMage>
I have the emmc chips I just havent installed them yet
matthias_bgg has joined #linux-rockchip
<PhoenixMage>
And I have liftoff
<PhoenixMage>
Thanks sigmaris it was an ATF problem
<sigmaris>
great, glad it's working :)
<PhoenixMage>
Me too, was doing my head in lol
<PhoenixMage>
Next challenge is to get it in SPI
<sigmaris>
ahh, I was trying that at the weekend, with no luck :(
<sigmaris>
with a *lot* of hacking I got it to load the SPL, but then it hangs loading ATF or u-boot.itb from SPI