SoSie

Well a picture to replace thousand words..

@ricardovasc and @hkkok be VERY CAREFULL USING the amixer spell from @MichaIng: # Reset and re-initiate ALSA mixer states rm /var/lib/alsa/asound.state alsactl init # Enable 3.5mm output amixer -c 0 set 'TOACODEC OUT EN' 'on' # Use I2S B as source for 3.5mm output, I2C A is somehow not usable amixer -c 0 set 'TOACODEC SRC' 'I2S B' # Use ALSA device 0 as input for I2S B amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' # Enable I2S B (SRC 2) on device 0 (_A) amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' # Set output channels for device 0 (_A) amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' # Set master volume to 85% amixer -c 0 set 'ACODEC' '85%' I have burnt my usb-audio device attached to so UNPLUG ANY USB AUDIO adapter and stuff as it seems to have burn by conflicting during the process. You have been warned, SoSIe

Hello, When we install armbian cinnammon, the eth0 ip is set default to 192.168.0.8. I cloned the installation and then the cloned conflicts with the source so I though to use armbian-config to change the IP adress. The ipv4 changed but I noticed warnings in/var/log/syslog : IPv6: eth0: IPv6 duplicate address.. It seems armbian-config does not update ipv6 or? What should be do, disable ipv6? I read it is not recommended at all.

Note that for the last line we can use also bpi-copy like: bpi-copy xxx.img.xz /dev/mmcblk1

It seems to be a alsa issue according to this post https://forum.odroid.com/viewtopic.php?t=41546 I am still on the previous armbian on my side using archive having booting or screen issues : https://imola.armbian.com/archive/bananapim5/archive/

Now, who want to be the Lord of the Flash and automatize this with a nice menu - why not in armbian-config which is a nice tool - to select the img.xz in live...this would simplify the task.?

Hello All, To all striking with sdcard issues , I have a good news today! NORMAL AND FIGHTING WAY Normally you put your sdcard on a adapter on a big computer you have flashed with a working and booting sbc to be able to flash the emmc and then you copy the .img.xz you have downloaded on it , put the card in the sbc and boot on it to have access to the dd command from there. Unfortunately the result will depend on your sdcard quality, I experienced many bad block so I get bored. Yesterday have a flash, LET'S TAKE THE BUNNY HIGHWAY! I found a way faster and safer to do it to circonvent the sdcard: tempfs! On the desktop computer, a linux machine, I download the images for the sbc wget https://imola.armbian.com/archive/bananapim5/archive/Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz wget https://imola.armbian.com/archive/bananapim5/archive/Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz.sha I retrieved the size du -h Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz 1,3G Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz I issued with the USER=pi created during the first boot install on the sbc, for me HOST=bananapim5 a ssh session, ip maye change depending on your setting in armbian_first_run.txt if you have set a static ip. Mine is 192.168.0.8 sosie@rainbow:~$ ssh pi@192.168.0.8 I tried the ubuntu tutorial to create tmpfs at a size a little bigger than the image .img.xz I want to flash #create the target directory for tempfs sudo mkdir /media/virtuelram #let only user access to their own temp files with the sticky bit sudo chmod 1777 /media/virtuelram #mount to have size M or g for gigas vitual drive sudo mount -t tmpfs -o size=1.5g tmpfs /media/virtuelram Exit to transfer the img.xz files by sftp IN THE BUNNY HIGHWAY ^o^ exit sosie@rainbow:~$ sftp pi@192.168.0.8 cd /media/virtualram mget Arm*.xz.* exit Now you are hundred percent to pass the exam (without cheating), the proof : sosie@rainbow:~$ ssh pi@192.168.0.8 cd /media/virtualram sha256sum -c Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz.sha Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz: Success The flash size is around 16go, we see can locate the EMMC, it's mmcblk1 , real size is 14.6Go USER@HOST:/media/virtuelram$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 59,5G 0 disk <== SDCARD 64Go └─mmcblk0p1 179:1 0 58,9G 0 part / mmcblk1 179:32 0 14,6G 0 disk <== EMMC └─mmcblk1p1 179:33 0 14,6G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk Now the fun part: sudo apt install xzcat pv dd sudo xzcat Armbian_22.08.7_Bananapim5_jammy_edge_5.19.16_cinnamon_desktop.img.xz | pv | dd of=/dev/mmcblk1 bs=10M status=noxfer

Issue is solved, the limitation was in Filezilla.. I uncheck Limitation of Transfert.

Hello, I want to transfer .img files to bananapi. These weight gigabytes. I notice the eth0 interface was wrongly set up to 100Mbp/s I used ethtool to set it up correctly pi@Liberty:~$ sudo ethtool eth0 | grep -i speed Speed: 100Mb/s sudo ethtool -s eth0 autoneg on speed 1000 duplex full pi@Liberty:~$ sudo ethtool eth0 | grep -i speed Speed: 1000Mb/s Now I thought the sftp limitation of 1Mb/s was over, it is not. Are there ucap / bandwith limitation settings in Armbian? if so how to remove it? Thanks, SoSie

Have you tried pavucontrol?, it's graphical and you will see if the app you are running gives something at input. You can redirect input to your hdmi, if hdmi is recognized as a output HDMI port.

Works fine when booting on 16go USB key 😃

WOAW THIS IS A AWESONE CAROT @igor !, I inform the owner of the deb-multimedia of this! If we can have an iso of it to feed ventoy that would very nice for x86/arm64 developers I confirm before having serious arm64 hardware, let's start with sdcard failures setting after a while system ro! Now I understand why flash.. EDIT: Humm I did not realized it was I think here; https://www.armbian.com/uefi-x86/ . I don't know if ventoy can boot on .img.xz, if not i will unpack to try on .img GREAT WORK THANXX A LOT! REPORT: @igor, the Armbian_22.11.1_Uefi-x86_jammy_current_5.15.80_cinnamon_desktop.img boots with ventoy but drops the user at initramfs stage (busybox) . We can thus don't use armbian-x86 as live distrib maybe the .iso I don't have works.

@Igor have a noob question for the new year of rabbit (we have had a parade previous year😞 does this distro can arm64 cross compile (I am tired to compile on bananapi m5 and now the debian multimedia maintainer tries to help the rabbit - who made vapoursynth working (unfortunately with no sound) for arm to be able to play any video) - but has no arm device under the hand?

Well @atone the 7" is 1024x600 59.8Hz the 23" is 1920x1080 60Hz the 7" can play 1k videos with not problem so ie h264 mp4 1920x1080 ones ONLY reduced to 1024x600. I tried with lower mp4 it does not work. I thinks it is a limitation of video decoder, I don't have this with my RPI3B.

@atone, I have just tested Bullseye XFCE desktop with the Kernel 6.1.14, Release date: Jan 9, 2023. Maybe it is just an Xorg issue as it boots correctly and display correct on my 23'' but not on 7' (no signal) so for now I freeezed the packages with apt-mark hold to prevent upgrades

@atone, @igor and the armbian team thanks for all yours efforts and answers, will check the new release. UPDATE with 6.1.14: -boot works 😃 -looses video signal on my 7'' screen after armbian logo -> console* -> back graphical *with error failed to start Access point and authentication for wifi and Ethernet : this is normal I don't have the wifi module) SO DOES NOT PASS THE TESTS, é_è so I stay with version 22.08.6

What @atone obtained , i got it too from Armbian_22.08.7_Bananapim5_bullseye_edge_5.19.16_minimal.img and after upgrading 5.19.16 (22.08.6) to 6.0.10 (22.11.30) with sudo apt upgrade linux-dtb-edge-meson64 sudo apt upgrade linux-image-edge-meson64 sudo apt upgrade linux-u-boot-bananapim5-edge as it removes 5.19.6 boot without asking your opinion, there is no way to go back except manually and externaly. the linux-* packages seems to be virtual, there is nothing in /var/cache/apt/archives FAILSAFE MODE: ============= What I did to come back in case some are stuck is to mount the partition armbi_root within the image decompacted losetup --partscan loop25 Armbian_22.08.7_Bananapim5_bullseye_edge_5.19.16_minimal.img At this point loop25p1 should be available to be mounted somewhere, ideally in /media/$USER/armbi_root. Now do (USER matches the current user USER=`whoami`) cp -a /media/$USER/armbi_root/boot/* <usb_card_root>/boot IMPORTANT: check the UUID in <usb_card_root>/boot/ArmbianEnv.txt matches the UUID declared in <usb_card_root>/etc/fstab, if not fix modify <usb_card_root>/boot/ArmbianEnv.txt ! don't forget to copy the modules.. cp -a /media/$USER/armbi_root/usr/lib/modules/* <usb_card_root>/usr/lib/modules umount <usb_card_root> Now let go back to the past in apt world too.. apt install linux-image-edge-meson64=22.08.6 linux-dtb-edge-meson64=22.08.6 linux-u-boot-bananapim5-edge=22.08.6 PUT & PRAY!!!! CONCLUSION: -The nice Armbian logo went away, even after apt going back (sorry i don't know how to restore it) but it boots back with the 5.19.16 kernel -REALLY HAVING NO FAILSAFE KERNEL IS A MESS! So..Yes multiboot would imho not be an option.

YES, I have tested the archive version on the sdcard directly the xfce image , it rocks, I wished to have found this working image earlier that uses kernel 5.19.16-meson64 that brings two huge differences: 1) screen autodetection is perfect (device name is correct and freq is not 0!) 2) enough lighweight to be able to run kodi debian which is a)very reactive b)saturates no processors , when playing mp4 -1024p, 25fps, H264, 128kbit AAC),,load is 200% and well balanced on the 4 cores (I have tested with ubuntu 22.10, raspian,... processor were busy at 70-90% EVEN DOING NOTHING!) SO WELL DONE @Igor and the whole Armbian team !!! for the upgrade of the U-BOOT partition, this is no more required unless we want multiboot...what about a bananaPINN with auto-install to sdcard, whith armbian chooser, installer direct in flash (let's dream for 2023)?

The big question is how to flush /boot/ kernel and u-boot updates made by debian after apt upgrade on the U-BOOT partition (BPI declares aarch64 whereas debian packages arm64) ? root@bananapim5:/usr/src# ls /boot/ armbianEnv.txt Image armbian_first_run.txt.template initrd.img-5.19.16-meson64 boot.bmp System.map-5.19.16-meson64 boot.cmd uImage boot.scr uInitrd config-5.19.16-meson64 uInitrd-5.19.16-meson64 dtb vmlinuz-5.19.16-meson64 dtb-5.19.16-meson64 root@bananapim5:/usr/src# uname -a Linux bananapim5 4.9.312-BPI-M5 #1 SMP PREEMPT Tue Sep 6 13:22:04 HKT 2022 aarch64 GNU/Linux

I confirm archive version boot on sdcard without problem, @igor using the same technique I described here There is simply a regression on armbian latest image 30nov imho as pointed by @atone

Well, it is not an sdcard issue @igor, I have tried previous Armbian_22.05.0-trunk_Bananapi-m5_bullseye_edge_5.17.5_minimal.img.xz with the first partition U-BOOT of Ubuntu 2022-09-06 release Ubuntu Mate Desktop 20.04 with Kernel 4.9 given by BPI Baidu Cloud: https://pan.baidu.com/s/1XE2K_KlVwP0hvjv_AChVgg?pwd=38vx (pincode: 38vx) Google drive: https://drive.google.com/file/d/1OGNaEylMR-VlfY6ynRkGQNuljLcvxoqe/view?usp=sharing MD5: 4b0528065ddcf634e9a43b6b7a6363b1 AND REPLACING U-ROOT content with the content of Armbian 22.05 using inside BPI-ROOT. Here are the ugly steps.. 1) Clean-up and prepare #we assume USER match current user (USER=`whoami`) cd /media/$USER/BPI-ROOT rm -r * sudo mkdir /mnt/arm-root 2) Mount the decompacted Armbian root from Armbian_22.05.0-trunk_Bananapi-m5_bullseye_edge_5.17.5_minimal.img with #from xz-utils sudo xz -d Armbian_22.05.0-trunk_Bananapi-m5_bullseye_edge_5.17.5_minimal.img.xz sudo kpartx -ar Armbian_22.05.0-trunk_Bananapi-m5_bullseye_edge_5.17.5_minimal.img I have a look which loop device has been created with lsblk as losetup -f is not reliable at all., for me it was /dev/loop6 sudo mount /dev/mapper/loop6p1 /mnt/arm-root 3) copied the arm-root content with sudo cp -a /mnt/arm-root/* /media/$USER/BPI-ROOT/ 4) Put the sdcard in the bananapi M5 and ladies ands gentlemens, it boots and I can even ssh to make a nice bunnyfied screenshot! Note the keyboard is American my bunny, can't we do an azerty jump for frenchies in the installation process since the first step just before entering password? sudo apt-get install keyboard-configuration locales console-setup-linux sudo dpkg-reconfigure keyboard-configuration sudo service keyboard-setup restart CONCLUSION: u-boot is a nightmare to make it work (I loose weeks trying to boot on different images that are not bootable in fact directly on sdcard) there should be a match with the kernel. I don't have the compatibility table to compile from u-boot github. I just saw Chewitt , main forum helper from Libreelec recommending to update u-boot. #USB/SD and eMMC images can be created with the same u-boot and instructions as any mainline u-boot using #Amlogic GXBB/GXL/GXM/G12A/G12B/SM1 board/device: #with https://chewitt.libreelec.tv/testing/u-boot/u-boot.bin.sd.bin-bananapi-m5 #see https://github.com/chewitt/u-boot/commits/amlogic-2021.07 dd if="/path/to/u-boot.bin.sd.bin" of="/dev/mmcblkX" conv=fsync,notrunc bs=1 count=444 dd if="/path/to/u-boot.bin.sd.bin" of="/dev/mmcblkX" conv=fsync,notrunc bs=512 skip=1 seek=1 It's nice, but with which file u-boot.bin is really compatible, this one?, with which modules and kernel, I did not manage to boot in the nighly build for now.. I guess you have to compile it from the sources..but which are compatible with BPI M5.? All stuff from BPI seems stalled to 4.9. documentation really lacks..Armbian declares using kernel 5.17.5 in /boot/ but i booted with 4.9.312-BPI-M5 thanks to Ubuntu team! However I prefer lightweight debian , debian 10 buster works with the same u-boot version so will test armbian now deeply which seems to have a nicer environment. It is the version jungle for 2023 in the bananapi kernel sources world !! Happy new Year!

Hello, I have tried Bullseye CLI image 30nov from https://www.armbian.com/bananapi-m5/ flashed with etcher to ensure integrity on sdcard sandisk A1 64G It appears that it loops in /scripts/local-block giving up to mount armbian root even with correct UUID why does it loop like this?