usual user

Members
  • Content Count

    20
  • Joined

  • Last visited

  1. As can be seen from the log (Executing backend \"/usr/lib/cups/backend/dnssd\"...) the cups backend is been started over and over again without succeeding in transfer any data to the printer. Maybe e.g. some firewall rules or something else network related is not setup properly. To approve this, connect the printer via USB and check if printing is working then.
  2. First step would be to enable "Save debugging information for troubleshooting" in the administration tab and inspect the log files.
  3. Does the image provided ---there---, put on a separate microSD with "xz -dcv Fedora-Minimal-armhfp-31-1.9-trial.raw.xz > /dev/sdX", boot for you properly? "/dev/sdX" has to be replaced by the device where the separate microSD resides while the transfer.
  4. Screenshot while transcode pipeline is running on the HummingBoard-i2-i-MX6-Dual-Lite. See conky panel for performance values.
  5. https://linuxtv.org/irc/irclogger_log/v4l?date=2019-11-01,Fri&sel=38#l34 \o/
  6. If I looked this up correctly from the i.MX 6Solo/6DualLite Applications Processor Reference Manual the VPU has this specs: HW Decoder: H.264 Profile: BP/CBP/MP/HP Resolution: 1080 i/p, 30 fps Bitrate: 50 Mbps HW Encoder: H.264 Profile: BP/CBP Resolution: 1080p, 30 fps Bitrate: 14 Mbps As the VPU is a dedicated IP the number of CPU cores does not matter for the codec performance and 1gb should suffice to provide the required buffer allocations for the intermediate frames. Just composed my first transcode pipeline, see transcode-pipeline.pdf for reference. I do not really know what I am doing (google was my friend) and there are so much knobs for configuration and fine tuning so YMMV. transcode-pipeline.pdf
  7. As the mentioned features are properties of the SoC it does not realy matter at which device the i.MX6 resides. Chose what fits your needs. As already stated to have all features out the box you need at least kernel 5.4.0-rc1. The rootfs distribution does not really matter as long as it provides software of the latest mainline releases. I tinker with cubox-i and hummingboard and as I wanted all bells and whistles I chose the quad variant with 2GB ram for me. This is working for me since round about fedora 26. OK, in the early days many of early adopter patches were required. But nowadays only proper configuration is necessary.
  8. You have to start here: https://www.kernel.org/doc/html/v5.3-rc3/usb/gadget_printer.html
  9. On imx6q SoC there is: v4l2-ctl --device=/dev/video0 --all v4l2-ctl --device=/dev/video1 --all v4l2-ctl --device=/dev/video10 --all /dev/video10 requires at least kernel 5.4.0-rc1 to work out of the box. gst-inspect-1.0 exposes: So hardware accelerated video pipelines can be composed in all flavors.
  10. In fedora these changes can`t land since the kernel is universal and device specific buildins are not allowed to prevent vmlinuz bloat. An initramfs is only required if you have an encrypted rootfs or want to use UUID or LABEL for rootfs identification. For this to work you need user space tools. The initramfs is highly rootfs dependent hence it is almost ever created on the fly while kernel package installation in the running system. Doing it in an offline manner is quite difficult if not impossible. For a not encrypted rootfs with PARTUUID the kernel can always find the rootfs as long as it has buildin support to access the rootfs. No matter at what block device the rootfs resides the kernel will find it. IMHO a distribution building device dedicated kernels should try to avoid using an initramfs. Without an initramfs installing a kernel boils down to copy preassembled files in place and point the boot loader at them. It can be done easily in an offline manner to recover a system and is rootfs independent as long as the files are copied in the correct location. I have done it with the fedora kernel to bootstrap the minimal armbian image. As a fly by, I thought I should report some observations. I don't care enough for armbian to get this included. An armbian supporter has to take over here.
  11. Boot without initrd with the current config-5.3.1-cubox is not possible. In fedora config I need at least to flip CONFIG_MMC_BLOCK, CONFIG_MMC_SDHCI, CONFIG_MMC_SDHCI_PLTFM and CONFIG_MMC_SDHCI_ESDHC_IMX from module to buildin to be able to boot without initramfs from mmc.
  12. If you have copied in /boot/vmlinuz-5.3.1-cubox, /boot/initrd.img-5.3.1-cubox, /boot/dtb-5.3.1-cubox/ and /lib/modules/5.3.1-cubox/ from your new SD install of 5.3.1 your only missing part should be to copy in the attached /boot/extlinux/extlinux.conf. extlinux.conf
  13. Dropping the bare image on the micro SD starts with working HDMI support. Maybe it is the different content of the initrd as that is the only difference to the previous used image kernel wise. But it is loading the wrong DTB (for cubox-i, not for hummingboard) and there is no visible cursor in the VT. Dropping in the attached /boot/extlinux/extlinux.conf fixes this. The first boot stanza doesn't even matter as uboot recognizes the missing files and gracefully skips to the second stanza. This gives a nice snappy desktop. extlinux.conf
  14. Your log shows the device is equipped with 1G of RAM, hence no cma is reserved. Etnaviv support should not be working, you probably need "cma=256M@1G" as a workaround.
  15. OK, figured what was going on. First step was to reinstall the armbian uboot from /usr/lib/linux-u-boot-next-cubox-i_5.98_armhf again. It has full distro boot feature available. I was mislead by a comment (# next kernels have different u-boot without autodetection) in /boot/boot.cmd. In the end uboot is setting up the boot parameters in a not suitable manner for my environment. And "Starting kernel ..." as the only feedback is not of much help to analyse the problem. I came up with the append line setup of the first boot stanza in /boot/extlinux/extlinux.conf to boot successful in my environment. In serial.log you see an automatic recover from a failing boot. Initially the fourth boot stanza is selected with boot parameters derived from /boot/boot.cmd. This is failing with "Starting kernel ...". After a while the watchdog kicks in and triggers a reset. Uboot restarts and autoboots the first boot stanza. The attached extlinux.conf can be used for the Armbian_5.98_Cubox-i_Debian_buster_next_5.3.1_minimal.7z as is. For other images the PARTUUID has to be adopted. "blkid" will tell you the proper value of your rootfs partition. serial.log extlinux.conf