Active threads

Hi Mark It looks like that python script might be using these commands. Try these commands maybe they'll work for you. https://github.com/arthur-liberman/linux_openvfd/blob/9264588ba27a964a1e56346202901dd17f9e133d/led_control.txt

Yes, the warpme patches adds a lot more features. Apritzel sources will mostly likely be mainlined. You can use Apritzel's kernel source and add warpme patches on top. I took the quickest route and just added all of warpme's patches. warpme: aliases { serial0 = &uart0; mmc0 = &mmc0; mmc1 = &mmc1; mmc2 = &mmc2; ethernet0 = &gmac0; ethernet1 = &gmac1; ethernet2 = &wlan; }; apritzel: aliases { serial0 = &uart0; }; &mmc0 { vmmc-supply = <&reg_cldo3>; cd-gpios = <&pio 5 6 (GPIO_ACTIVE_LOW | GPIO_PULL_DOWN)>; /* PF6 */ bus-width = <4>; status = "okay"; };

Nice progress. I think that your SPI, DC, CS, RESET configurations are correct. DONT CHANGE THOSE Regarding the ili9341 vs ili9486 driver... hopefully you will find an example using the ilitek,ili9486 driver, with a correct init parameter. (check that the init is the same as the people having success in https://forum.armbian.com/topic/11701-35-lcd-ili9486-with-orange-pi-zero/#comment-86679 ) With the correct init parameter, you configure the LCD to receive the data in the correct pixel format and ordering, to match the format sent by the CPU. Also, it configures VCOM, a key parameter that I think is electrical and not data related... read the LCD manual, I can't remember what it is for. Search for ili9486 in the raspberry pi forum. Maybne someone figured it out already. Here's how I used the mipi driver for the ili9488, based on someone's success with Raspberry Pi https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/#findComment-207964

Ooo changed the dtd ,and now it's booting perfectly 😋

It sounds wrong. There is no degradation in speed. Also, your assumption about SSC of the clock generator is wrong as well. According to datasheet of AU5426, it does not support SSC

That seems like sw from vendor. eMMC onboard memory needs to be erased. Check docs, I don't know by heart how to do it. Maybe there is some pin that can be shorted to ground to disable it. Or there is some tools or flash mode to erase/skip it. Once eMMC is nuked booting from microsd should work just fine.

Yes of course, there is such a file '/boot/armbianEnv.txt', but it is generated on the fly by the Armbian build system and if you don't know this build system in and out, you are pretty easily lost ... You have to set specific environment variables and put the file mentioned in my post in a specific folder and then a valid and correct armbianEnv.txt will be generated by the build system. I'm thinking about how I manage to get this in the standard Armbian build. I don't want to mess with the complex build process only to do something that is very specific for my TV box.

Hello everyone! I have a mxq Box with txcz-mxq-ep-v10 board rk3228a processor, the only multitool image that works is bad-trust, even so it works for about 30 seconds then it turns off (black screen), what could be wrong? Thank you very much!

They have identical firmware. Try most recent 25.2 images https://www.armbian.com/bananapi-m5/ Our test device runs fine - up-time 6 days ATM.

Last week I managed to complete first part of run-time desktop deployment script. It might serve as a starting point of what you want to achieve. https://github.com/armbian/configng/pull/436

It seems there is smth on the flash preventing boot, so I would remove SD card, enter mask rom, release button or other contact used to enter maskrom (it is necessary only to "tell" to bootrom that no internal flash is available for boot) and format/erase flash. After that disconnect the device from PC and power, and then reconnect/power on device, it should enter maskrom by itself since internal flash is empty. Then just boot from SD card with appropriate armbian image.

The only solution is to do it as sns1081 suggested. Or you can try nano pi M6 dietpi IMG. That one works actually albeit with some glitches. I was never able to flash any of img from armbian directly. Images that actually works: rockchip Ubuntu (Joshua riek), but I read it's not maintained anymore (install via rkdevtool [Windows] or rkdeveloptool [Ubuntu, Linux mint doesn't work, didn't try other OS]. It supports VPU, that is you can watch 4K 60fps YouTube with few dropped frames (meaning that GPU/VPU drivers still not optimal, as android runs 8k). There is bredOS for rockchip3588 devices, which is arch based. If you're familiar with arch, it's easy. I kinda liked it as it boots from 90s BIOS style UEFI with clean and simple interface, where you can do some basic configs like changing .dtb and stuff :), but does not support you/gpu. Unfortunately all of OS'es installation done via mask ROM. Life would be much easier if it was possible to flash SD, insert into orange pi, copy OS to Emmc, change boot order to EMMC... Like you do in raspberry pi. What else? Btw building armbian or dietpi yourself bricks the device and then you need reflash it again. Will update if find anything else: haven't tried fedoras or SUSEs yet..

# Europe/Moscow - 2000 Mbit/s - server: stpete-mirror.armbian.com/beta/ rules: - field: location.country.iso_code not_in: - UA latitude: 59.9417 longitude: 30.3096 weight: 10 # Europe/Kiev - 1000 Mbit/s - server: fastmirror.pp.ua/armbian/ rules: - field: location.country.iso_code not_in: - RU latitude: 50.458 longitude: 30.5303 weight: 10 After this change, our redirector blocks access to Russian mirrors for users in Ukraine and vice versa. Hopefully, this feature will become obsolete soon.

We're proud to announce that Whisper is now available in Hindi! With 2,500 hours of Hindi speech data and innovative techniques like Indic Normalization, this model sets a new benchmark for Hindi ASR. View the full article

I think I'm seeing the same issue as described in OP. wpa_supplicant[25499]: wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='xxx' freq=2452 MHz) wpa_supplicant[25499]: FT: Invalid key management type (2) wpa_supplicant[25499]: wlan0: Association request to the driver failed Restarting wpa_supplicant (the network is controlled by ifupdown in my case) does not help. FT hints that the issue is related to 802.11r Fast Transition feature, and here's the similar (although not the same) bug described in NetworkManager: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/4

Hi @Werner, I have the same problem (beta.armbian.com 502 Bad Gateway [IP: 130.185.239.78 80])

uart RTD1395PU baud rate: 115200

apt install build-essential kmod debhelper devscripts linux-headers-current-sunxi then "git clone" the driver and follow README inside please let me know if you got it working or not

Im using Orange Pi PC+ with Debian 12 minimal image. I tryed to install/compile ovpn-dco-v2 as of standard deb (openvpn-dco-dkms) as well as of git (https://github.com/OpenVPN/ovpn-dco). In bouth cases compilation prcess itself was finished successfully but resulting driver ovpn-dco-v2.ko didn't work. In the first case, the driver caused a kernel error. In the second case, after "modprobe ovpn-dco-v2" , openvpn stuck somewhere in the middle and lsmod has hung down, blocking the console. Before installing the driver package i did: apt install build-essential kmod debhelper devscripts linux-headers-current-sunxi And as i thought everything went fine. What did I do wrong? Which linux headers do I need to install: "current" or maybe "edge". Maybe some dependencies are broken... On x86 Debian everything works fine. Any ideas?

In your log you will see: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Armbian 25.5.0-trunk.61 bookworm 6.12.13-current-meson64 Retrieving file: /vmlinuz-6.12.13-current-meson64 Skipping l0 for failure retrieving kernel 2: Armbian 25.5.0-trunk.61 bookworm 6.12.13-current-meson64 (rescue target) Retrieving file: /vmlinuz-6.12.13-current-meson64 Skipping l0r for failure retrieving kernel EXTLINUX FAILED: continuing... 78003 bytes read in 43 ms (1.7 MiB/s) Card did not respond to voltage select! : -110 Card did not respond to voltage select! : -110 This means that uboot can't reliably read your media.

Thanks so much for entertaining my issue. I rebuilt my image without the custom compiled module (which I needed to do in the past), and it just worked. You guys are the best. This issue is solved. It was not an Armbian issue.

This is a very interesting topic I will try to apply it when I need a fast 3.3V output on startup. I am dealing with LCD screens right now, and I know 3 ways to display something on screen faster: * compiling the LCD driver(s) into the kernel (with the * option instead of "M" in Linux kernel config) * make uboot drive the LCD display (https://github.com/robutest/u-boot/blob/master/drivers/video/ili9341.c) * instead of compiling a DTBO to overlay after startup, add the "blob" in the main DT itself and uboot wont lose time on that (there's a discussion about that in onf of the opiz3 gpio threads) (but I haven't tried any of them)

This is how network is set for some time now: https://docs.armbian.com/User-Guide_Networking/

Kernel 6.12 does not have hdmi patches. You have to go back to 6.6 or 6.7. I would use the dts I posted above. This dts has the proper settings for your pmic axp305/806. Changing axp313a to axp806 without changing the rest of the settings can be dangerous. There are no dram settings in the dts. Everything ram related is done in the uboot defconfig. So use this defconfig from the patches posted above and add your lpddr3 settings. Change everything with CONFIG_SUNXI_DRAM_* the rest can stay the same. (remove the plus infront of each CONFIG. This was taken from a patch) +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_DEFAULT_DEVICE_TREE="allwinner/sun50i-h313-x96q-ddr3" +CONFIG_SPL=y +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y +CONFIG_DRAM_CLK=600 +CONFIG_DRAM_ODT_EN=y +CONFIG_DRAM_SUN50I_H616_UNKNOWN_FEATURE=y +CONFIG_DRAM_SUN50I_H616_BIT_DELAY_COMPENSATION=y +CONFIG_DRAM_SUN50I_H616_READ_CALIBRATION=y +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x03030303 +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x00001c16 +CONFIG_DRAM_SUN50I_H616_ODT_EN=0x1 +CONFIG_DRAM_SUN50I_H616_TPR0=0xc0000007 +CONFIG_DRAM_SUN50I_H616_TPR2=0x00000100 +CONFIG_DRAM_SUN50I_H616_TPR10=0x002f6606 +CONFIG_DRAM_SUN50I_H616_TPR11=0xffffdddd +CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7657 +CONFIG_MACH_SUN50I_H616=y +CONFIG_R_I2C_ENABLE=y +CONFIG_SPL_I2C=y +CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_SYS_I2C_MVTWSI=y +CONFIG_SYS_I2C_SLAVE=0x7f +CONFIG_SYS_I2C_SPEED=100000 +CONFIG_PHY_REALTEK=y +CONFIG_SUN8I_EMAC=y +CONFIG_I2C3_ENABLE=y +CONFIG_SUNXI_RVBAR_ALTERNATIVE=0x81000040 +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_MUSB_GADGET=y +CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x40 +CONFIG_MMC_SUNXI_SLOT_EXTRA=2

Can someone help me how I can fix my kernel build system? Whatever image I flash on my board, the armbian-config -> "install kernel headers" function does not install everything needed to compile the kernel.