17:02 <checkpoint> Hi all. Is there any way to boot 3.14.113 kernel on A13 ? I cannot find proper kernel config, whatever I try it just hangs right after "Starting kernel ...", kernel version 3.4.103 boots ok.

17:35 <montjoie> checkpoint: such old kernel! very few people will still use it

18:13 <libv> checkpoint: you might want to explain what you want to achieve first

18:59 <hexdump0815> jernej: warpme: i just built a v5.15.11 kernel for a qplus h6 tv box and added the h6 related patches (for eth etc.) from minimyth2 ... it looks good so far, but hdmi-out does not work

18:59 <hexdump0815> it works well with v5.10 - full dmesg is: https://pastebin.com/raw/s6uzWzW3 - the relevant line seems to be "sun4i-drm display-engine: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-12)"

18:59 <hexdump0815> is there anything special to keep in mind or any known problem with v5.15 on h6?

19:00 <hexdump0815> used config: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/blob/master/config.ah6

19:01 <hexdump0815> used patches: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/tree/master/misc.ah6/patches/minimyth2 without the "maybe" subdir

19:33 <checkpoint> montjoie: unfortunately that is the only way to use hardware accelerated H264 codecs, encoding is still not iplemented in mainline.

19:35 <checkpoint> libv: I want to boot 3.4.113 kernel on A13, I need hardware H264 codecs and OV5640 driver that is implemented in 3.4.113.

19:35 <gamiee> checkpoint: I get H.264 encoding working on mainline kernel (using binary blob)

19:36 <checkpoint> gamiee: got any web resource on how to achieve that ? We have H264 working using libcedar on 3.4, but how to get it working on mainline ?

19:37 <gamiee> @checkpoint : https://github.com/aodzip/libcedarc

19:37 <gamiee> I have verified that it works just fine, I'm working on GStreamer plugin which uses the libcedar for encoding

19:39 <checkpoint> gamiee: what driver does it use ? /dev/cedar_dev ?

19:39 <gamiee> cedar kernel module + ion

19:40 <checkpoint> gamiee: that's interesting, thanks

19:41 <gamiee> @checkpoint: No problem! If you will have any other questions, ping me here.

19:42 <gamiee> Also, I started to reverse engineer the libcedar blob here: https://github.com/gamelaster/pinecube/tree/main/software/recedar , although, I was reverse engineering the old CAMdroid blob, and after I will finish GStreamer plugin, I plan to start reimplementing the latest one, so it will be easier to test it.

19:46 <checkpoint> gamiee: we have our own software that does H264 encoding pipelining images from camera to encoder eliminating memcpy, works quite efficiently on 3.4.103 (better than ffmpeg). The problem is that ov5640 driver in 3.4.103 is incredibly lame witten. we tested 3.4.133 on T2, it works way better (gives better image quality and FPS). So we decided to build 3.4.113 for A13 as well and that's were we got stuck - kernel does not boot.

19:48 <gamiee> @checkpoint: as you might know, debugging allwinner's bsp is pain, so I can't give you any hints, but I think you should be able to get your software working on mainline just fine. OV5640 works on mainline just good :) PineCube on which I test everything have the same sensor

19:52 <checkpoint> gamiee: yes, switching to mainline was one of the planned ways to go for us, yet I could not find any info on how to use encoding in mainline. I read about cedrus which does hardware accelerated decoding, but it seems abandoned, so we stick with 3.4 kernel.

19:53 <gamiee> @checkpoint: cedrus is not abandoned, it's already done and working on mainline kernel for a longer time (but only decoding)

19:56 <gamiee> that's what I'm trying to do, recedar is first step, second step is to get this into cedrus :)

19:57 <checkpoint> gamiee: I will be grateful if you do it! thanks!

19:59 <checkpoint> we are also trying to get rid of buggy A13 switching to T3, but that takes a log of work to redesign our hardware.

20:00 <checkpoint> s/log/lot/

20:00 <gamiee> what was buggy on A13?

20:04 <checkpoint> gamiee: among other things, H264 hw encoder on A13 generates bogus P frames and we had to work around that. Exactly same code on A20/T2 works fine.

20:07 <checkpoint> gmiee: could be a bug in a blog, I don't really know, but damn annoying.

20:07 <gamiee> @checkpoint: on A20 and on A13, you use same libcedar blob, or different one? If same, it's definitely core bug

20:07 <checkpoint> s/blog/blob/

20:08 <checkpoint> gamiee: same libcedar, yes

20:08 <gamiee> then it's silicon bug

20:08 <checkpoint> gamiee: we managed to patch it somehow, to skip bogus P frames.

21:02 <jernej> hexdump0815: -12 means -ENOMEM, so increase CMA size? or alternatively, disable fbdev emulation or at least disable additional memory allocation for doublebuffering on fbdev

21:02 <jernej> H6 DRM driver should work well in almost all cases in 5.15

21:03 <jernej> the only outstanding issue is 4k@60 with some monitors or TVs, but I have patch for that too (in testing phase)

21:30 <checkpoint> can someone please tell is it feasible to achieve 1920x1080@30fsp using CSI DVP camera interface, not LVDS ?

21:32 <libv> checkpoint: yes.

21:32 <libv> with csi being the allwinner definition of csi

21:36 <libv> whether the a13 can handle the memory bandwidth that the csi engine throws out is something else

21:37 <libv> but a20 is happy doing double that

21:40 <checkpoint> libv: good, thanks.

21:42 <checkpoint> libv: btw, what camera sensors do you think can handle that ?

21:42 <libv> i used a dvi to parallel chip, the ti TFP401

21:42 <libv> as that came on a handy module

21:42 <libv> https://archive.fosdem.org/2020/schedule/event/videobox/

21:43 <checkpoint> that's cool

21:43 <checkpoint> I watched your video on youtube :)

21:46 <libv> :)

21:49 <libv> that was running 1280x720@60Hz for two days straight

21:50 <checkpoint> yeah..

21:50 <libv> early testing had it running full hd for much longer, but that was not needed for the physical fosdem setup of the time

21:51 <libv> if we are lucky, we actually can do full hd with the available memory bandwidth, but wait and see

22:09 <hexdump0815> jernej: thanks a lot - i think this goes into the right direction: CONFIG_CMA was not set :)