divis1969
-
Posts
67 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by divis1969
-
-
I also had some time to complete this exercise.
I didn't realize the commamd-not-found is the package, but it prevented me from completing apt update after the do-release-upgrade failure. I've simply manually removed /var/lib/command-not-found folder.
Then I followed the typical procedure (sometimes called 'Debian way'?):
sudo sed -i 's/bionic/focal/g' /etc/apt/sources.list.d/armbian.list sudo sed -i 's/bionic/focal/g' /etc/apt/sources.list sudo apt update sudo apt -y dist-upgrade
Everything was fine, I was asked to manually select which configuration file I would prefer - maintainer or current one - for few packages (sshd, ngnix, etc). I'd selected the existing ones in all the cases.
Now I have the following greeting:
Welcome to Armbian 21.02.2 Bionic with Linux 5.10.21-sunxi
And 'Ubuntu 20.04.2 LTS' for lsb_release.
As for the 'sudo do-release-upgrade --allow-third-party' I suppose Armbian should probably change the naming of the 'components' part of the armbian.list data source(s) (Unless there is a way to specify the proper way to modify it by do-release-upgrade scripts. I didn't find it).
-
Ok, I've tried with enabled third party:
$ sudo apt install ubuntu-release-upgrader-core $ sudo do-release-upgrade --allow-third-party
This failed with the following errors:
W:Skipping acquire of configured file 'bionic-utils/binary-armhf/Packages' as repository 'http://apt.armbian.com focal InRelease' doesn't have the component 'bionic-utils' (component misspelt in sources.list?), W:Skipping acquire of configured file 'bionic-utils/cnf/Commands-armhf' as repository 'http://apt.armbian.com focal InRelease' doesn't have the component 'bionic-utils' (component misspelt in sources.list?), W:Skipping acquire of configured file 'bionic-desktop/binary-armhf/Packages' as repository 'http://apt.armbian.com focal InRelease' doesn't have the component 'bionic-desktop' (component misspelt in sources.list?), W:Skipping acquire of configured file 'bionic-desktop/cnf/Commands-armhf' as repository 'http://apt.armbian.com focal InRelease' doesn't have the component 'bionic-desktop' (component misspelt in sources.list?), E:Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi', E:Sub-process returned an error code
Content of /etc/apt/sources.list.d/armbian.list:
deb http://apt.armbian.com bionic main bionic-utils bionic-desktop
I have yet no idea what to do with that. Are those bionic-utils and bionic-desktop excluded from focal sources list ?
-
On 1/19/2021 at 12:12 AM, Igor said:
Hardware interface for your unknown hardware (is it supported at all?)Banana PI. A20. Initially this topic was posted in the appropriate forum.
On 1/19/2021 at 12:12 AM, Igor said:but we have no resources to support you on just every problem you might find.
The question was: why do I need to freeze it from technical POV.
I do understand your team have limitations on support. The device I'm going to play with is mostly used for testing purposes, so if I completely fail with upgrade, I will do a clean install.
And thanks for the great job.
On 1/19/2021 at 12:28 AM, SteeMan said:I tried this upgrade a few months back
Do you mean do-release-upgrade or manual source list change?
I see there is some way to enable the 3rd party update along with the system upgrade (https://ubuntu.com/blog/how-to-upgrade-from-ubuntu-18-04-lts-to-20-04-lts-today , see Advanced options & third-party software).
Maybe I could try this and enable armbian repositories.
-
Isn't it better to install ubuntu-release-upgrader-core and use the do-release-upgrade instead of manual procedure?
Can/Should I freeze kernel upgdade with it? Why do I need to freeze it, btw?
-
Is there any recommendations how to upgrade Armbian from Ubuntu Bionic to Ubuntu Focal?
-
Thanks for the tip!
BTW, I've got a crash stack for a segmentation fault I've mentioned above:
Thread 1 "ffmpeg" received signal SIGSEGV, Segmentation fault. tiled_to_planar () at tiled_yuv.S:86 86 vld1.8 {d0 - d3}, [SRC :256], TSIZE (gdb) bt #0 tiled_to_planar () at tiled_yuv.S:86 #1 0xb6fc25b0 in copy_surface_to_image (driver_data=driver_data@entry=0x466960, surface_object=surface_object@entry=0x469f48, image=image@entry=0xbeffda44) at image.c:159 #2 0xb6fc280e in RequestDeriveImage (context=<optimized out>, surface_id=67108864, image=0xbeffda44) at image.c:200 #3 0xb5a5eb84 in ?? () from /usr/lib/arm-linux-gnueabihf/libavutil.so.55 Backtrace stopped: previous frame identical to this frame (corrupt stack?)@All Is that something known already?
-
I've tried to ask a question in IRC channel (#cedrus on freenode) but did not get an answer (or maybe I've missed it while I was offline, do not know where to get backlog).
If you mean to update a library by myself, I do not have any experience with H264 (or other video codecs).
The goal was to get a quick estimation whether cedrus is good enough for video surveillance application.
-
Re-encoding from 25fps to 5fps (sw-to-sw and hw-to-sw) are almost identical though the second case takes more time (copying hw buffers?):
$ time ffmpeg -hwaccel vaapi -hwaccel_device /dev/video0 -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -c:v libx264 -r 5 -an stream.mp4 ... real 6m45.657s user 10m44.271s sys 0m13.720s $ time ffmpeg -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -c:v libx264 -r 5 -an stream_sw.mp4 ... real 6m20.538s user 10m19.009s sys 0m3.729s
The video produced with hw decoder has small artifacts at the bottom-right corner.
-
I have reverted the following commits:
341772b82a3b media: cedrus: Specify H264 startcode and decoding mode 8cae93e09011 media: uapi: h264: Add the concept of start code 5604be66a568 media: uapi: h264: Add the concept of decoding mode
Now I can run decoding of H264:
$ export LIBVA_DRIVER_NAME=v4l2_request $ time ffmpeg -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null ... real 0m15.255s user 0m5.651s sys 0m1.693s
Average speed is ~5.3x, fps ~130
There are some errors at the end though:
[AVHWFramesContext @ 0xae54cfe0] Failed to destroy surface 0x400000b: 6 (invalid VASurfaceID).
Here is the test of decoding without hardware:
$ time ffmpeg -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null real 0m37.776s user 0m57.906s sys 0m1.983s
Average speed is ~2.0x, fps ~50
I also tried to decode in software and encode in hardware. This causes crash of ffmpeg (I was not able to get a stack with gdb yet):
ffmpeg -vaapi_device /dev/video0 -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -vf 'format=nv12,hwupload' -c:v h264_vaapi -an stream.mp4 ... Segmentation fault
-
I've found that the issue with h264 codec is caused by the size of the struct v4l2_ctrl_h264_slice_params defined in include/media/h264-ctrls.h (kernel) and include/h264-ctrls.h (libva-v4l2-request).
Kernel's version adds one more field start_byte_offset with commit
commit 5604be66a56867a784e162299a48c214921ffa1b Author: Boris Brezillon <boris.brezillon@collabora.com> Date: Fri Aug 16 13:01:24 2019 -0300 media: uapi: h264: Add the concept of decoding modeI did not find any changes in libva-v4l2-request that match this change in kernel.
I'm going to revert the above commit to test whether this can fix the issue.
-
There was no /etc/default/cpufrequtils in my case but /etc/default/cpufrequtils.dpkg-old instead. I've copied it to /etc/default/cpufrequtils, replaced 'ondemand' to 'performance' and rebooted a device.
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance
Uptime is 23 hours at the moment.
-
I'm also observing similar issue (device is not accessible via ssh after some time - from few hours to couple days). This happened with kernels 5.3.x (don't remember exactly which one I've installed) and the same 5.4.35 (I'm using Ubuntu).
-
On 4/27/2020 at 11:13 AM, MacBreaker said:
Did you try out Zoneminder? I think about to try it in the next time when i've time.
Yes, I did. If was long time ago and I found kerberosio more attractive. There was also a performace issue with ZM on bananapi that time.
I've tested ZM recently again (on bananapi m3) and it seems using less CPU than kerberosio while movement detection. So, I would switch to ZM if it will be able to handle >1 cameras.
But I decided to first play with HW decoding on bananapi prior to migrating to ZM.-----
Here are the results of my attempt to use cedrus.
- I've built libva-v4l2-request. There were few issues with it. It requires libva-dev and libdrm-dev, I've installed it with apt.
Version release-2019.03 of libva-v4l2-request failed on build due to libva-dev version mismatch (this package seems declared incorrect verion for pkg-config).
I've switched to a tip of the master branch was built successfully (but with small change in the /usr/include/linux/videodev2.h - I've added v4l2_timeval_to_ns which
is missing. BTW, I've also installed linux headers with apt, these headers contain v4l2_timeval_to_ns but libva-v4l2-request does not use these)This lib is installed by default to /usr/lib/dri/, but libVA will search it under /usr/lib/arm-linux-gnueabihf/dri/ and I've just create a symbolic link. Maybe --prefic should be specified to autoconf instead.
- I've tried to use this lib with ffmpeg (default, installed with apt):export LIBVA_DRIVER_NAME=v4l2_request ffmpeg -v verbose -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -r 5 -an stream.mp4
It produces the following error:
[AVHWDeviceContext @ 0x1d7a820] libva: VA-API version 1.1.0 [AVHWDeviceContext @ 0x1d7a820] libva: va_getDriverName() returns -1 [AVHWDeviceContext @ 0x1d7a820] libva: User requested driver 'v4l2_request' [AVHWDeviceContext @ 0x1d7a820] libva: Trying to open /usr/lib/arm-linux-gnueabihf/dri/v4l2_request_drv_video.so [AVHWDeviceContext @ 0x1d7a820] libva: Found init function __vaDriverInit_1_1 [AVHWDeviceContext @ 0x1d7a820] libva: va_openDriver() returns 0 [AVHWDeviceContext @ 0x1d7a820] Initialised VAAPI connection: version 1.1 [AVHWDeviceContext @ 0x1d7a820] Unknown driver "v4l2-request", assuming standard behaviour. Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Press [q] to stop, [?] for help [h264 @ 0x1d77fc0] Reinit context to 1280x720, pix_fmt: vaapi_vld v4l2-request: Unable to set control: Bad address v4l2-request: Unable to queue media request: No such file or directory [h264 @ 0x1d77fc0] Failed to end picture decode issue: 1 (operation failed). [h264 @ 0x1d77fc0] hardware accelerator failed to decode picture
Kernel log also contains errors:
[94838.781065] cedrus 1c0e000.video-codec: Missing required codec control [94838.785428] cedrus 1c0e000.video-codec: Missing required codec control [94838.791230] cedrus 1c0e000.video-codec: Missing required codec control [94838.794613] cedrus 1c0e000.video-codec: Missing required codec control
- I've built v4l2-request-test and play with it. Initially it complains "Unable to start display engine" so, I've commented this functionality (so it can decode, but does not try to display frames).
This suite contains several test packages (frames). MPEG2 tests works perfectly (decoding only, as I said).H265 tests fail with error Processing frame 1/50 Loaded 145064 bytes of video slice data Unable to set control: Bad address
There was no kernel errors.
H264 tests are disabled because of absence of V4L2_PIX_FMT_H264_SLICE in the system headers (linux headers contain it but autoconf does not see those).Any suggestions how to enable H264? Should I also rebuild the kernel? What's wrong with H265?
-
Hi,
Did anybody play with Cedrus on the recent kernels?
I'm going to play with it on Bananapi m1, kernel 5.4 and Ubuntu Bionic.
Should I just got step-by-step using this instructions http://linux-sunxi.org/Sunxi-Cedrus ?
The goal is to evaluate whether this is suitable solution for video surveillnace. I'd used kerberosio with an IP camera for couple years and this does not work good with motion detection.
-
Well, I did not find the exact reason why there was no kernel logs. Most likely I've removed SD card from card reader without proper ejecting.
I've spent some time creating a suitable development environment (I've found Armbian is not
userdeveloper-friendy) and finally was able to figure out the reason of the boot failure.That is a patch/kernel/sunxi-current/0111-mfd-axp20x-Add-AC-power-supply-cell-for-AXP813.patch which adds a duplicate entry axp20x-ac-power-supply into a cell list of axp20x MFD device.
I've renamed this patch to *.disabled, rebuilt the kernel and it has booted successfully from SD card (did not yet try to install bootloader and system to emmc - I've removed previous one in assumption it affects the boot, actually not).
As for the dev env: what is the best practice to modify and re-build a kernel in Armbian build system? The simplest way seems to create a patch and place it somewhere under patch/kernel. That is because build system cleans the kernel unconditionally.
-
Well, I've built the Armbian and tried to run it from SD.
Unfortunately, it enters boot loop. I've attached the log from console.
I'm not familiar with u-boot, it looks like u-boot is loaded from SD, but all the boot scripts were taken from mmc (I did not remove my previous OS from it).
Note that I've set verbosity to 7 and console to serial in SD's /boot/armbianEnv.txt and the same should still persist in the mmc's /boot/armbianEnv.txt, but there is no logs from kernel boot. Weird...
Can I prevent u-boot to read boot scripts from emmc?
-
55 minutes ago, Igor said:
How is this possible? We haven't put out a kernel upgrade yet. At least not on a stable kernel branch. Nightly or development builds are for testings only and anything can happen there.
I'm not sure. Perhaps I had enabled this manually, or I had started from dev build a long time ago... Sudo apt upgrade had upgraded the kernel as well. First time I had just recovered from this by booting from sd card and modifying links at emmc /boot for kernel and dtb and copying initram from sd. This time I've first collected this log.
Well, hopefully I will have some time to debug it.
-
Hi,
I had Armbian based on kernel 4.19 installed on emmc. It was running pretty good for a long time but recently it was automatically upgraded to kernel 5.3.9 and started to restart while booting.
I had collected a log (see attachment),
It looks like it was unable to find root partition and this is most likely caused by issue with axp20x_device_probe.
Is this a known issue? Is there any remedy?
-
On 5/8/2019 at 2:08 PM, mutluit said:
Is there a way to find out which DTB is currently loaded?
Check 'cat /proc/device-tree/model' or other nodes under /proc/device-tree. This is the loaded device tree seen by kernel.
-
And what is the final configuration: versions of u-boot, kernel and dtb (was linux-dtb-next-sunxi updated in any of the test above)?
-
Well, that's all I can do. I suppose some debugging is needed for u-boot and/or kernel.
Hm, one more crazy idea:
what if install the 5.65 (from SD and transfer to nand) first and upgrade to 5.75 on a running board? The idea is to upgrade kernel and system but not the u-boot. Not sure this is possible however...
-
Ok, this kernel obviously can detect the USB drive.
I've noticed USB could be initialized a little bit later than systemd tries to mount a root partition.
On my board dmesg shows first ext4 mount at ~6s, whereas USB hub is inited at ~9.2s.
Perhaps USB init is not yet completed in your case too.
I doubt I can help with the exact root cause for this (whether this is u-boot issue or another reason).
I would propose to delay the kernel boot for few seconds, maybe u-boot or armbian can be configured somehow to delay it.
You can try also to reboot the board with reset key after the failed pendrive boot - just to check whether USB init is the reason (this might not help, but who knows...)
-
Well, and what is the output of 2 more commands?
# lsusb Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # ls -l /sys/bus/usb/devices/ total 0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 1-0:1.0 -> ../../../devices/platform/soc@1c00000/1c14000.usb/usb1/1-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 2-0:1.0 -> ../../../devices/platform/soc@1c00000/1c1c000.usb/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 3-0:1.0 -> ../../../devices/platform/soc@1c00000/1c14400.usb/usb3/3-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 4-0:1.0 -> ../../../devices/platform/soc@1c00000/1c1c400.usb/usb4/4-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 5-0:1.0 -> ../../../devices/platform/soc@1c00000/1c13000.usb/musb-hdrc.1.auto/usb5/5-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb1 -> ../../../devices/platform/soc@1c00000/1c14000.usb/usb1 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb2 -> ../../../devices/platform/soc@1c00000/1c1c000.usb/usb2 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb3 -> ../../../devices/platform/soc@1c00000/1c14400.usb/usb3 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb4 -> ../../../devices/platform/soc@1c00000/1c1c400.usb/usb4 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb5 -> ../../../devices/platform/soc@1c00000/1c13000.usb/musb-hdrc.1.auto/usb5
Does the previous comment (ls phy@1c13400) match the log of "5.75 u-boot" log ? Can you see any USB device with this boot with lsusb?
-
I suppose investigating of this issue needs better-than-mine understanding of low level details (u-boot, at least).
I see some suspicious logs in u-boot:
EHCI failed to shut down host controller. EHCI failed to shut down host controller.
Also, the size of device tree decreased from 71000 (5.65) to 70000 (5.75)
That's probably ok, but I would try to check the integrity of device tree.
For example, the presence of the following node in the device tree (on running kernel):
# ls /proc/device-tree/soc@1c00000/phy@1c13400/ '#phy-cells' clocks name pinctrl-0 reg reset-names status usb0_vbus-supply usb1_vbus-supply clock-names compatible phandle pinctrl-names reg-names resets usb0_id_det-gpio usb0_vbus_power-supply usb2_vbus-supply
Please check this node if you can boot from SD card with 5.75.
Boot from MTD with 23.02.2
in Rockchip
Posted
Hi,
I've booted the board from SD card with the latest image and I'm trying to configure the board to boot from MTD and use USB drive as a system drive.
When running armbian-config (or armbian-install, or nand-sata-install), it fails with error "SPI u-boot image not found!".
It looks like the bootloader package is missing the /usr/lib/linux-u-boot-current-rock64_23.02.2_arm64/rkspi_loader.img.
Can I find it anywhere?
Dmitry