schunckt

Hi all! I may need some pointers. I'm using a 2.4" LCD at spi1 which works as /dev/fb0 on armbian bookworm (6.1.63) Meanwhile I've learned frambuffer is deprecated and to be replaced by drm., but ... - I could not find enough details to understand the drm architecture in general - there is a linux/drivers/gpu/drm/tiny/ili9341.c how is that used at all? - How to use drm in armbian? For my case any acceleration is not necessary (and likely not possible even if the H3 has Mali Hardware) but I want to avoid further changes if /fbX is really gone. btw. I want to add touch with shared SPI soon, work in progress. Of course that should also work then later on with drm - I'm thinking of any possible conflicts inside the Device Tree which then may need further tweaking. It's all nice but sooooooo time consuming... T.

I can confirm 6.1.47 now works! One caveat: Highest resolution 2592x1944 still has the cma/dma memory error like 6.4.x. But as of now I don't mind. I'll focus next on the harware encoding and other hardware resting, Thilo

Great! I'll give it a try, likely next weekend. Thilo

@going "Maybe it's a hardware limitation?" this can't be true because highest resolution works with the "original" friendlyCore 4.14 image/kernel. @Gunjan Gupta im quite sure 2592x1944 worked in Armbian_21.08.1_Nanopiduo2_focal_current_5.10.60 but i can retry using the prepared SD card (I hope this still is there 🙂) About 6.1: I don't mind if it only works on the latest 6.4x series, I'm fine staying there and proceed with other development like hwaccell and other stuff, like spi display retest and the like. FYI using the "friendly" I already was able to capture and playback on fbi / spi display, other i2c sensors are working, ola DMX output works, .net6 works with swagger UI ... Goal is have this all working in latest armbian plus hwaccel (if possible) btw. if you really find the root cause in 6.1 don't hesitate to share the source code of the problematic area. I'm curious... Thanks! Thilo

@going it seems the higest resolution 2592x1944 fails because of this: [ 593.498632] cma: cma_alloc: reserved: alloc failed, req-size: 1846 pages, ret: -16 [ 593.498684] sun6i-csi 1cb0000.camera: dma alloc of size 7561216 failed already increased cma to 256M but doesnt help. Anyway. Will proceed next with the encoder/decoder and fullhd 1920x1080 (works), that's more important for me. Thilo

Did further play around with ffmpeg and v4l pipeline. This now WORKS also 6.4.8-sunxi (Armbian_23.08.0-trunk_Nanopiduo2_jammy_edge_6.4.8_minimal build from 07-Aug) v4l2-ctl --device /dev/video1 --set-fmt-video=width=1280,height=720,pixelformat=YUYV media-ctl --device /dev/media1 --set-v4l2 '"ov5640 2-003c":0[fmt:YUYV8_2X8/1280x720]' ffmpeg -i /dev/video1 -q 10 -pix_fmt yuv420p -video_size 1280x720 -r 5 -listen 1 -f avi http://192.168.179.55:8080/stream VLC http://192.168.179.55:8080/stream ffmpeg is version 4.4.2-0ubuntu0.22.04.1 This means, there was a problem "behind the scenes" in 6.1x which is now fixed. Other parameters which did work in the past and now failing might be a side effect of internal improvments. I'll figure out anyway because this kernel now also contains the cedrus video engine and I want to use that for encoding and decoding. So from my point of view the issue is solved. @going the highest resolution 2592x1944 did work in friendlycore xenial 4.14 so the driver WAS able to do so. Don't know yet if something is now broken - but as said above need to play around anyways. Thanks @all! Thilo

Progress still on nanopiduo2 6.4.8-sunxi Meaniwhile i tried ustreamer which now WORKS at least with 640x480 like so: v4l2-ctl --device /dev/video1 --set-fmt-video=width=640,height=480,pixelformat=YUYV media-ctl --device /dev/media1 --set-v4l2 '"ov5640 2-003c":0[fmt:YUYV8_2X8/640x480]' ./ustreamer -d /dev/video1 --host 192.168.179.55 -r 640x480 and VLC plays http://192.168.179.55:8080/stream will now go ahead trying ffmpeg and will test ustreamer on 6.1.x (But I'd prefer using latest build anyway!) Thanks! Thilo

Did build 'edge' have now Linux nanopiduo2 6.4.8-sunxi #1 SMP Thu Aug 3 08:26:15 UTC 2023 armv7l armv7l armv7l GNU/Linux No more crashes 😀 but now no video🙄. mjpg_streamer says "cant enable video" dmesg shows sun6i-csi 1cb0000.camera: invalid input/output format combination tried sveral params which did work in the past, no luck as yet. Will do further testing later on. v4l2-ctl -d /dev/video1 --all Driver Info: Driver name : sun6i-csi Card type : sun6i-csi-capture Bus info : platform:1cb0000.camera Driver version : 6.4.8 Capabilities : 0xa4200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x24200001 Video Capture Streaming Extended Pix Format Media Driver Info: Driver name : sun6i-csi Model : Allwinner A31 CSI Device Serial : Bus info : platform:1cb0000.camera Media version : 6.4.8 Hardware revision: 0x00000000 (0) Driver version : 6.4.8 Interface Info: ID : 0x0300000e Type : V4L Video Entity Info: ID : 0x0000000c (12) Name : sun6i-csi-capture Function : V4L2 I/O Pad 0x0100000d : 0: Sink, Must Connect Link 0x02000010: from remote pad 0x1000003 of entity 'sun6i-csi-bridge' (Video Interface Bridge): Data, Enabled, Immutable Priority: 2 Video input : 0 (sun6i-csi-capture: ok) Format Video Capture: Width/Height : 640/480 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Bytes per Line : 1280 Size Image : 614400 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Limited Range) Flags : looks good but that "sun6i-csi-bridge" seems to be different!?! also i have spi-spidev overlay enabled but there is no /dev/spi* Maybe I made something wrong when building the image!?!? ov5640 load shows root@nanopiduo2:~# dmesg | grep ov5640 [ 8.767826] ov5640 2-003c: supply DOVDD not found, using dummy regulator [ 8.768164] ov5640 2-003c: supply AVDD not found, using dummy regulator [ 8.768320] ov5640 2-003c: supply DVDD not found, using dummy regulator [ 8.775980] ov5640 2-003c: Consider updating driver ov5640 to match on endpoints The last line is new i think. Need to figure out what that means... Thilo

I've a armbian VM build environment ready, did build once successfully but I'm not experienced in linux. Is there an easy way to find and integrate the changes mentioned above? Then I could give it a try, maybe just the code to be pasted into the respecitve files... Thilo

Update: after boot simple v4l2-ctl -d /dev/video1 --all also causes the crash. Output ends here in the middle: Driver Info: Driver name : sun6i-csi Card type : sun6i-csi Bus info : platform:1cb0000.camera Driver version : 6.1.34 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Media Driver Info: Driver name : sun6i-csi Model : Allwinner A31 CSI Device Serial : Bus info : platform:1cb0000.camera Media version : 6.1.34 Hardware revision: 0x00000000 (0) Driver version : 6.1.34 Interface Info: ID : 0x03000003 Type : V4L Video Entity Info: ID : 0x00000001 (1) Name : sun6i-csi Function : V4L2 I/O Pad 0x01000002 : 0: Sink, Must Connect Link 0x02000007: from remote pad 0x1000006 of entity 'ov5640 2-003c' (Camera Sensor): Data, Enabled Priority: 2 Video input : 0 (Camera: ok) Format Video Capture: Width/Height : 1280/720 Pixel Format : 'BA81' (8-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1280 Size Image : 921600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : Thilo

Did you ever solve this? Maybe try this: media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY8_2X8/1920x1080]' note the _2X8 (I found this while searching for latest DT overlay) T.

Just FYI i did update/upgrade recently and just NOW again but the result is the same. Will test latest image just in case. Thanks! Thilo

Done. Here is the link https://paste.armbian.com/ufihilozam Thilo

Hi there! I've recently configured the ov5640 camera overlay and was able to capture videos either with mjpg-streamer of ffmpeg. Now on 6.1.34 both causes now a kernel oops. From the stack trace it looks like it happens inside v4l2 "media_pad_remote_pad_first" Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... ... PC is at media_pad_remote_pad_first+0xa/0x58 I don't think v4l2 is the root cause because this may mean it fails alle the time which is unlikely. Looks like a null ptr gets passed in into media_pad_remote_pad_first ffmpeg used like this, but other parameters all resulting in the kernel oops at the same location. sudo media-ctl --device /dev/media1 --set-v4l2 '"ov5640 2-003c":0[fmt:UYVY8_2X8/1280x720@1/15]' ffmpeg -hwaccel_device 0 -framerate 15 -f v4l2 -video_size 1280x720 -i /dev/video1 -r 15 -pix_fmt yuv420p -b:v 1280k test1280-15.mp4 WORKS on 4.14.x (was video0 and media0 here) mjpeg streamer testing ./mjpg_streamer -i "./input_uvc.so -d /dev/video0 -y 1 -r 1920x1080 -f 5 -q 30 -n " -o "./output_http.so -w ./www" Possible root causes: 1) Something is now wrong inside my DT overlay due to kernel changes? I'm thinking about the i2c and spi relationships 2) Something is broken inside ov5640 driver 3) Something is broken inside v4l Maybe someone can provide some hints to point me in the right direction for further investigation? Attached are the dmesg output and overlay source. Thilo mjpg-streamer with camera overlay oops 06.08.2023 output.txt sun8i-h3-ov5640.dts

YES, thats great! In fact I realized it's supported state later after my post. T.

Sry. the existing search tags are fine 🙂 Would be nice to have a separate forum for Nanopi Duo2. T.

Regarding the fixed dts, can one provide the original dts? I'd like to have some base to diff because i want to figure out what has been changed. I'll try to port these to a Nannopi Duo2 6.1.30 T.

Does that really work? It looks like the overlay mixes SPI0 and SPI1 which are two different separated SPI controllers inside the SOC (of course the NEO only has SPI0 on it's pins) Beside that the dts uses PA6 which isn't wired. What's its purpose? T.

Armbian_23.5.2_Nanopiduo2_bookworm_current_6.1.30.img works, had to fix wired ethernet. See other topic if interested in https://forum.armbian.com/topic/28911-nanopi-duo2-wired-ethernet-fix-bookworm-6130-tested/ also it seems armbian-config doesn't work properly. I had to enable spi and i2c overlays manually (not really a problem IMHO) . T.

Image Armbian_23.5.2_Nanopiduo2_bookworm_current_6.1.30.img uname -a Linux nanopiduo2 6.1.30-sunxi #1 SMP Wed May 24 16:32:53 UTC 2023 armv7l GNU/Linux It turns out the dtb has some missing pieces: ethernet@1c30000 { compatible = "allwinner,sun8i-h3-emac"; syscon = <0x1e>; reg = <0x1c30000 0x10000>; interrupts = <0x00 0x52 0x04>; interrupt-names = "macirq"; resets = <0x03 0x0c>; reset-names = "stmmaceth"; clocks = <0x03 0x1b>; clock-names = "stmmaceth"; status = "okay"; phy-handle = <0x69>; // differs from NEO phy-mode = "mii"; allwinner,leds-active-low; after adding phy-handle, phy-mode and allwinner.. wired ethernet works. Of course NetworkManager config /etc/network interfaces must be configured properly. In my case # Network is managed by Network manager auto lo iface lo inet loopback # network interface not managed by Network Manager allow-hotplug eth0 iface eth0 inet static address 192.168.179.222 netmask 255.255.255.0 gateway 192.168.179.1 dns-nameservers 192.168.179.1 Possibly the leds* are not required. Maybe these can be tweaked for other IO's then 🙂 btw. would be nice to thave a separate Nanopi duo2 section here. T.

Your log shows several Warnings. Does the dtc still output the dtbo? If yes Maybe it works despite the warnings? T.

Hi! That sounds interesting to me as well. I'll give it a try on a NanoPi Duo2 5.10.34-sunxi Does that solution use the vaapi layer? Forgot to mention - possibly this is no longer necessary at all since the cedrus driver already appears as /dev/video0 but im still unsure if and how this is usable ... T.

Hi! I'm quite sure this is (was) a bug because I fixed it Here's howto. I'd like to provide (attach here) the overlay dts / dtbo but that doesnt seem to be possible or allowed here?! the built overlay-ov5640.dts has been derieved from an OrangePi One H3 and power pin GPIOs adjusted / removed then compiled into dtbo https://forum.armbian.com/topic/13238-ov5640-device-tree-overlay-for-orangepi-one-h3/page/3/ compile and copy the overlay dtc -I dts -O dtb -o overlay-ov5640.dtbo overlay-ov5640.dts cp /root/overlay-ov5640.dtbo /boot/dtb/overlay/sun8i-h3-ov5640.dtbo finally the boot env has been adjusted cd /boot nano armbianEnv.txt add the ov5640 to the "overlays" list. Note that the copied file above follows the naming conventions like the others. overlays=i2c0 i2c1 i2c2 usbhost0 usbhost2 usbhost3 ov5640 after reboot one should have now a /dev/video1 and /dev/media1 device. Note that /dev/video0 still seems to be the cedrus decoder only (not yet further investigated) Note that the overlay enables the Pullups on i2c2 which isn't necessary on the NanoPi Duo2 because it has 1k on board as per schematics but it doesnt hurt. mjpeg_streamer works with some parameter tweaking. ffmpeg works as well but needs lots of more parameter tuning. Next story is to get hardware acceleration working (cedrus) ideally for encoding and decoding h264. T. overlay-ov5640.dts overlay-ov5640.dtbo

Hi folks! So first here is the key question: Did anyone get exactly this combination NanoPi Duo2, ov5640 camera, armbian focal running? If YES, HOW … ? 😊 Details below. btw. buster would be also fine... uname -a output is Linux nanopiduo2 5.10.34-sunxi #21.05.1 SMP Thu May 6 20:13:21 UTC 2021 armv7l armv7l armv7l GNU/Linux I’m quite new to Linux and Armbian and have a slight problem using an Nanopi Duo2 and an ov5640 camera. It works pretty well using the image from FriendlyElec. This has been tested using the mjpg-streamer. Due to this success I’m sure the entire hardware setup is correct. Unfortunately the ov5640 camera does not work using mjpg-streamer as before with the armbian focal image. Also some testing with ffmpeg did not work. I can explain in more detail what “does not work” means. Ideally I’d like to have the mjpg-streamer (or the later experimental) in a working shape for testing purposes. THEN I can decide how to proceed with my own development. ffmpeg would be also okay for testing. For me it looks like ffmpeg fails for other reasons. I did dig through several newsgroups but could not identify the root cause. Here is what I verified or tested: 1) i2cdetect 2 output is correct. It shows the device on address 0x3c I’m not sure if that worked from the beginning after several changes but this didn’t impact at all the failing camera. 2) v4l2-ctl --list-devices cedrus (platform:cedrus): /dev/video0 /dev/media0 3) v4l2-ctl --list-formats ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'ST12' (Sunxi Tiled NV12 Format, compressed) [1]: 'NV12' (Y/CbCr 4:2:0) 4) modprobe ov5640 does not show any errors inside the dmesg output. Interestingly after rmmod and modprobe frame_rate=2 there IS an error “unknown parameter”. This means THIS current module as part of the kernel doesn’t have that parameter as specified elsewhere. 5) I also played a little with dtb overlays but still no success. The last “hardcore test” 😊 was putting in the friendlyArm dtb into the armbian image but that caused other errors. Thanks in advance!