Active threads

Hi Werner, weirdly it seems to be this wiring. In any case I get a readout. _____UART____ /Pin 4 - VCC| red |Pin 3 - TXD| |Pin 2 - RXD| \Pin 1 - GND| black However, I am now confronted with the prompt "nextcloudpi login". "root" and "ncp" do not work, nor any of my other logins. I am using a PW manager, so it cannot really be that I am getting anything wrong. Do you know what the cause could be?

The only thing I haven't been able to eliminate is this message [ 5.019754] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file I tried setting the GPIO flag for GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN but unfortunately, it doesn't work but it doesn't affect the operation of w1-gpio It seems that the GPIO pins do not have an "open drain" mode, they do outputs and inputs. It is a warning about what something sees as an invalid or incomplete configuration in Device Tree, rather than a real problem with the hardware.

I replaced the build/packages/Plymouth - theme - armbian logo and recompile, but generated firmware boot or the default image display, be sure to perform the update - initramfs - u can success to replace, What should I do to replace it in the generated firmware

Planned point release and images rebuild date is upcoming Saturday, 25th. There are three problems, that would be nice to fix before. People working on are very busy and might not be able to deal with, so help is needed here: Debian bookworm XFCE lacks wallpaper and lockscreen Compile from sources and pack Chromium for aarch64 on PPA Resolving Noble incompatibility with amazingfated-rk3588 extension Thank you all that participated in this release!

Description I guess all these BOOTFS_TYPE come from https://github.com/armbian/build/pull/3874. Rock3a and other rk356x boards uses an old version of vendor u-boot: https://github.com/radxa/u-boot/tree/stable-4.19-rock3, which has bad support for ext4 filesystem. While rk3588 uses new version of vendor u-boot which doesn't have ext4 partition issue, so I just drop all this config from rk3588 boards. Command to query boards with this config: grep -rn rockchip-rk3588 config/boards/|awk -F ':' '{print $1}'|xargs grep BOOTFS_TYPE Here are the vendor uboot source of these boards: board vendor uboot source armsom-sige7 armsom-w3 nanopc-cm3588-nas nanopct6 nanopi-r6s rock-5b https://github.com/radxa/u-boot/tree/next-dev-v2024.03 fxblox-rk1 https://github.com/functionland/u-boot/tree/next-dev indiedroid-nova https://github.com/stvhay/u-boot/tree/rockchip-rk3588-unified orangepi5-plus orangepi5pro https://github.com/orangepi-xunlong/u-boot-orangepi/tree/v2017.09-rk3588 orangepi5 https://github.com/u-boot/u-boot/tree/2f0282922b2c458eea7f85c500a948a587437b63 How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] ./compile.sh build BOARD=rock-5b BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DEB_COMPRESS=xz DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base ENABLE_EXTENSIONS='rk-panthor mesa-oibaf rk-multimedia-amazingfate' KERNEL_CONFIGURE=no KERNEL_GIT=shallow RELEASE=noble Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

The repository exist again, but is empty as focal is EOS (End of Support status) for Armbian

finally bluetooth is working with such config: &uart0 { status = "okay"; uart-has-rtscts; bluetooth { pinctrl-names = "default"; compatible = "brcm,bcm43438-bt"; max-speed = <4000000>; clocks = <&rk805 0x01>; clock-names = "extclk"; shutdown-gpios = <&gpio1 RK_PC5 GPIO_ACTIVE_HIGH>; host-wakeup-gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>; }; }; firmware from android partition: sha256sum BCM4343B0.hcd 2252534aa755ab2857eb9765c55eb1d917e77992b5ee2ff701955cdcda9a8c9a BCM4343B0.hcd

Hello all! After upgrading to OMV 7 and Debian 12 my OLED display remains dark. I am using Kobol Helios 4 NAS. Can anyone tell me where the problem is? When i try to execute git clone https://github.com/kobol-io/sys-oled.git cd sys-oled sudo ./install.sh I get the following error message via SSH. Installing luma.oled library error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. Installing sys-oled files 'etc/sys-oled.conf' -> '/etc/sys-oled.conf' 'bin/sys-oled' -> '/usr/local/bin/sys-oled' 'share/sys-oled/C&C Red Alert [INET].ttf' -> '/usr/local/share/sys-oled/C&C Red Alert [INET].ttf' 'share/sys-oled/helios4_logo.png' -> '/usr/local/share/sys-oled/helios4_logo.png' 'system/sys-oled.service' -> '/etc/systemd/system/sys-oled.service' Enabling sys-oled at startup Does anyone have an Idea what to do?

I have reinstall the device and the docker. However, I need to install the firmware 5.10.160. Indeed the nanopc-t6 don ot star with any image with firmware 6.1.43 or 6.8.9. I do not understand why ?. Apprently I understand that you are able to install the version 6.1.43 without issue. Could you please explain me the procedure you have used ? Thanks in advance for your support.

This was more of an fyi. I am happy running the v20 image.

I think Windows Drives Management has difficulty with understanding Linux partitions. Hopefully SD Formatter detects SD cards without assigned drive letter. It formats cards to FAT16 and then Drives Management sees that drive and allows assigning drive letter. After that I was able to test one of my Kingston cards. h2test2 output: Warning: Only 14795 of 14796 MByte tested. Test finished without errors. You can now delete the test files *.h2w or verify them again. Writing speed: 9.82 MByte/s Reading speed: 77.9 MByte/s H2testw v1.4 Not very fast but with no problems. So I used that card and burned Armbian with balena Etcher. Earlier I wad using Rufus. After all, booting stops in the same place.

find a board with u-boot 2024 and rebase your board config file I use OrangePi3B as a base config

https://drive.google.com/file/d/1n_sMewTbbszuEFHhpL-dNqHBiOwUtdJT/view Part 2.6

Can't find that image anywhere and no matter what i try (even the banana pi supplyed ones) refuse to boot into emmc. When going into the U-Boot shell with a SD-Card plugged in i can get this env => env print arch=arm baudrate=115200 board=sunxi board_name=sunxi boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr -q ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi boot_efi_bootmgr=if fdt addr -q ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf} boot_net_usb_start=usb start boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg boot_scripts=boot.scr.uimg boot.scr boot_syslinux_conf=extlinux/extlinux.conf boot_targets=fel mmc_auto usb0 pxe dhcp bootcmd=run distro_bootcmd bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr -q ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci; bootcmd_fel=if test -n ${fel_booted} && test -n ${fel_scriptaddr}; then echo '(FEL boot)'; source ${fel_scriptaddr}; fi bootcmd_mmc0=devnum=0; run mmc_boot bootcmd_mmc1=devnum=1; run mmc_boot bootcmd_mmc_auto=if test ${mmc_bootdev} -eq 1; then run bootcmd_mmc1; run bootcmd_mmc0; elif test ${mmc_bootdev} -eq 0; then run bootcmd_mmc0; run bootcmd_mmc1; fi bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi bootcmd_usb0=devnum=0; run usb_boot bootdelay=1 bootm_size=0xa000000 console=ttyS0,115200 cpu=armv7 dfu_alt_info_ram=kernel ram 0x42000000 0x1000000;fdt ram 0x43000000 0x100000;ramdisk ram 0x43400000 0x4000000 distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done efi_dtb_prefixes=/ /dtb/ /dtb/current/ ethaddr=02:01:7e:b0:bb:78 fdt_addr_r=0x43000000 fdtcontroladdr=bbf5e620 fdtfile=sun8i-a83t-bananapi-m3.dtb fdtoverlay_addr_r=0x43300000 kernel_addr_r=0x42000000 load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile} loadaddr=0x42000000 loadsplash= for prefix in ${boot_prefixes}; do if test -e mmc 0 ${prefix}boot.bmp; then load mmc 0 ${splashimage} ${prefix}boot.bmp; bmp d ${splashimage}; fi; done mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi mmc_bootdev=0 partitions=name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};name=loader2,size=984k,uuid=${uuid_gpt_loader2};name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};name=system,size=-,uuid=${uuid_gpt_system}; preboot=usb start pxefile_addr_r=0x43200000 ramdisk_addr_r=0x43400000 scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi; scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done scriptaddr=0x43100000 serial#=32c004017eb0bb78 soc=sunxi splashimage=66000000 splashpos=m,m stderr=serial stdin=serial,usbkbd stdout=serial usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi uuid_gpt_esp=c12a7328-f81f-11d2-ba4b-00a0c93ec93b uuid_gpt_system=69dad710-2ce4-4e3c-b16c-21a1d49abed3 Environment size: 4905/65532 bytes Also i can access the emmc once booted @Gunjan Gupta Do you have any idea where to go from here or where to find more info on how to maybe get it booting from emmc ?

@ebin-dev You are not alone, I also use the 2.5GB interface 😉

I have a very good understanding of bash commands I just read it differently than you intended, everything actually worked without applying the patch so I'm not sure what we've achieved. What doesn't work is downloading a fresh clone - thanks for your help Edit Someone must have merged the fix into the current tree as it now works perfectly again - thanks again

The problem is that everything worked fine (with normal HDMI cable, 4K screen and stable Armbian 24.2.1 ). And suddenly on the next usual boot, there was no video output and no screen detected in settings. I've checked cable and monitor with another devices - everything works fine. I've checked another normal HDMI cable and monitor with this Orange PI 5 - no output detected. Also I can still see video using type-c to DisplayPort output. So the problem is something wrong with HDMI output. Either on firmware level (I have lots of error using sudo update/upgrade the last time everything worked ), or on hardware level (maybe something on my SBC just broken/heated due to poor quality). I flashed firmware several times and it didn't help

Hi Fedes_gl! HDMI is working, but I could not play any video or audio due to missing applications and any internet connection.

Description After testing, it was found that Firefly-RK3399 cannot boot using the mainline device tree due to issues with the PMU (Power Management Unit). Even after fixing the PMU problem, Bluetooth still cannot be used. Therefore, the original patch has been optimized by removing unnecessary parts. How Has This Been Tested? [x] Almost all hardware functions(HDMI, WiFi, BT, GbE, USB...). [x] System startup. Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

lib & config: give shellcheck directions (to /dev/null for dynamic, to repo-relative path for static) for all sourced references lib & config: give shellcheck directions (to /dev/null for dynamic, to repo-relative path for static) for all sourced references in preparation for tightening the shellcheck severity level it needs to be able to follow all sources; dynamic ones are ignored, static ones need root-relative prefix View the full article

t95z: add board file (and u-boot 2024.04) for T95Z Plus Amlogic tvbox t95z: add board file (and u-boot 2024.04) for T95Z Plus Amlogic tvbox we've had kernel patches/DT (from chewitt) for this in meson64 for a long time, but I never sent the board uses blobs for the tartiflette-s912 which is also an DDR3 S912 (VIM2's blobs are DDR4 and won't boot) this adds u-boot 2024.04 support, using chewitt's DT & 000.patching_config.yaml & a specific BOOTPATCHDIR this is a full board as-if it was an SBC, and expects to boot from mainline u-boot; for that to work you've to wipe the eMMC and get rid of the vendor-supplied u-boot if this is not what you want/need, you can use the aml tvbox "board" instead, together with Android u-boot View the full article

khadas-vim3: fix stray closing brace in board file khadas-vim3: fix stray closing brace in board file a stray closing brace, meant for the function, that ends up doing the wrong config change View the full article

"OLED stats working also in debian, you need to activate I2C5 M3 overlay in orangepi-config" By doing above, do you still need to execute point #1 (add overlay) from original instructions?

@JohnTheCoolingFan neither am I familiar with much of that. I'd just like to say that H618 support evolves out of H616 and the DTS for Orange Pi Zero 3 and Zero 2W is contributed by Andre Przywara from 6.6 mainline kernel. But that various contributors here worked the DTS further, check in the thread for details. Note that there are also change in *u-boot* for Orange Pi Zero 3, mainly to add the PMIC and DDR4 support for Orange Pi Zero 3 I think some key difference between Orange Pi Zero 2 (H616) vs Orange Pi Zero 3 (H618) are : - PMIC the power management IC is different - Orange Pi Zero 3 uses lpddr4 vs Orange Pi Zero 2 lpddr3 various other 'small' differences and that H618 is after all based on H616 codebase. Hence, my guess is to attempt to use the 6.6 and up mainline kernel and do a rebuild for CB1. One thing I'm not sure is where to configure that so that the build would use the 6.6.x mainline kernel during the build. It would likely 'not build cleanly' (e.g. without errors) and the build errors especially if the 'old' patches for the same board is applied and those would need to be resolved. You would take into account the actual hardware differences vs Orange Pi Zero 2 or Orange Pi Zero 3 if after all they are different on the CB1.

Description Issue reported from radxa's forum: https://forum.radxa.com/t/the-changable-wifi-interface-name-of-rock-5c-lite/20921 Rock5c has an onboard aic8800 usb wifi/bt module, which has random wifi interface name by default, which will cause non-static connection name created by networkmanager. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] PREFER_DOCKER=no ./compile.sh kernel BOARD=rock-5c BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DEB_COMPRESS=xz KERNEL_CONFIGURE=no RELEASE=jammy KERNEL_GIT=shallow DESKTOP_APPGROUPS_SELECTED= DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article