All Activity

does emmc working yet?

armbianmonitor - u result: https://paste.armbian.com/nocetohemu Best regards Rolf

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

**1. Summary:** The text console (`tty1`) is permanently stuck at 30 rows by 90 columns after boot, despite the DRM/KMS framebuffer being correctly set to 1920x1080 resolution. All attempts to change the console size via boot parameters, sysfs, or runtime tools fail. This breaks the basic CLI experience on displays larger than VGA. **2. Environment:** * **Hardware:** Orange Pi PC (Allwinner H3) * **Image/Distribution:** "Forky" (appears to be an Armbian-based rolling Debian fork) * **Kernel:** `6.12.68-current-sunxi` (build@armbian) #1 SMP Fri Jan 30 09:28:49 UTC 2026 * **Graphics Stack:** Modern DRM/KMS (`sun4i-drm`). The legacy `fb` driver is not active. * **Monitor:** Connected via HDMI. EDID is correctly read (tested with `modetest`). **3. Steps to Reproduce:** 1. Boot the system with the affected image on an Orange Pi PC. 2. Log in to the text console (`tty1`). 3. Run `stty size`. It will always return `30 90`. 4. Observe that the terminal only uses the top-left quarter of a 1920x1080 display. **4. Diagnostic Evidence:** ```bash # Console size is fixed and wrong: $ stty size < /dev/tty1 30 90 # Framebuffer is provided by DRM and reports correct resolution: $ cat /sys/class/graphics/fb0/name sun4i-drmdrmfb $ cat /sys/class/drm/card0/card0-HDMI-A-1/modes | head -1 1920x1080 # Kernel boot parameters (from /proc/cmdline) include video settings, but are ignored: root=UUID=... video=HDMI-A-1:1920x1080@60 console=tty1 ... # All attempted fixes that FAILED: # - Boot parameters: `fbcon=font:VGA8x16`, `vt.global_cursor_default=0`, `drm_kms_helper.edid_firmware=...` # - Runtime commands: `resizecons`, `setupcon`, `stty rows cols`, writing to `/sys/class/graphics/fbcon/` # - Service restarts: `getty@tty1`, `gpm` ``` **5. Expected Behavior:** The text console should automatically scale to use the full resolution of the framebuffer. For a 1920x1080 framebuffer with an 8x16 font, the expected `stty size` should be approximately `67 240` (or `67 120` for a 16x16 font). The console should fill the entire display. **6. Additional Notes:** * The same hardware works correctly with a **Debian Bookworm** image and an older kernel, where console auto-scaling functions perfectly. * This indicates a **regression** in the `6.12.68-current-sunxi` kernel build or its DRM/KMS configuration for the Allwinner H3. * The bug makes the distribution unsuitable for any headless or console-focused use case on this hardware. **7. Questions for Maintainers:** * Is there a specific kernel configuration option (`CONFIG_*`) for Allwinner H3 DRM that controls TTY auto-scaling? * Has the `vt` or `drm` subsystem changed in a way that requires new boot parameters for this hardware? * Can this be worked around without a kernel recompile?

@Nick A Oh yeah, I did change a few things as well for type c. Maybe the drm heap changes are not needed after all. Looking at my changes. husb311 is now under drivers/power/typec, so just enable it. et7304 is not included in the original bsp, radxa team added them later so simply apply this same patch. https://github.com/radxa/allwinner-bsp/commit/156b6578cc173855b41ea311a229403ccbadb17c

We have progress, sorry I feel like I'm spamming this thread a bit but at least I have a result. Wifi is now working. Still no bluetooth. For anyone playing at home with this box, to get to this point I installed x98h image from Nick's github. I then downloaded the following files from walnutpi's github fw_patch_table_u03.bin fw_adid_u03.bin fw_patch_u03.bin fmacfw.bin aic_userconfig.txt I copied these files to the device and placed them in /lib/firmware/aic8800_sdio/ Then shutdown the unit and powered it back up. Doing a restart isn't enough, you need to shut it down. So just bluetooth to go. The only related message seems to be sdio_err: <aicwf_sdio_bus_pwrctl,1380>: bus down Which I expect will probably require me to update the dtb settings as previously discussed. Happy to settle with just the wifi working but I'll take a shot at getting bluetooth going because I may as well finish what I started. Thanks for the help thus far. edit: I've tried decompiling the /boot/dtb/allwinner/sun50i-h618-x98h.dtb file but I can't find any of the relevant info to change in the dts file. It's like the sections listed in the patch file linked earlier are not there at all. I understand it's in a different format but as an example. The following section line 278 to 297 +&uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; + uart-has-rtscts; + status = "okay"; + + bluetooth { + compatible = "allwinner,sunxi-btlpm"; + // max-speed = <1500000>; + + clocks = <&rtc 1>; + clock-names = "lpo"; + vbat-supply = <&reg_dldo1>; + vddio-supply = <&reg_dldo1>; + enable-gpios = <&pio 6 19 GPIO_ACTIVE_HIGH>; /* PH19 bt_power */ + reset-gpios = <&pio 6 13 GPIO_ACTIVE_LOW>; /* PH13 bt_rst_n */ + device-wakeup-gpios = <&pio 6 17 GPIO_ACTIVE_HIGH>; /* PH17 bt_wake */ + host-wakeup-gpios = <&pio 6 16 GPIO_ACTIVE_HIGH>; /* PH16 bt_hostwake */ + }; +}; I've tried searching the dts file for "uart1", "bluetooth", "bt", "btlpm", "lpo", the hex equivalent of the values above, all the different value names etc... of the small amount of results that do show up, most of them are not even remotely close to matching anything above. "usart1" does have a section detailing the pins and rtscts but it seems that bluetooth section just isn't there. This is just one example, lines 87 to 102 don't appear to be there either. There is some values for vcc-3v3 but that's it. I'll probably have to look at updating the values in the patch file and building an image.

@jock Thank you for the information, I just updated the thread removing the requirement to use CMA=256. as per openauto it doesn't require cma to be set at 256. Will release the cursor patch with some adjustments to ffmpeg and some GUI changes (mostly settings adjustment)

@Bones558 @alexc I noticed that a few USB-C drivers are missing in the 6.6 kernel. While the Makefile and Kconfig files are present, they have changed. In the 5.15 BSP, the bsp/drivers/usb/typec/tcpm directory contains tcpci_et7304.c and tcpci_husb311.c, but in 6.6, this directory is empty. 6.6: bsp/drivers/usb/typec/tcpm$ ls Kconfig Makefile 5.15: bsp/drivers/usb/typec/tcpm$ ls Kconfig Makefile tcpci_et7304.c tcpci_husb311.c

@Nick A @Bones558 Hi there, I am not sure if that's definitely due to DRM heap. But I fixed that driver and it could be built now. I didn't know if USB C DP works or not before but it is working now (on a USB C monitor, maybe needs a few re-plug). I opened a PR on Radxa allwinner-bsp github (https://github.com/radxa/allwinner-bsp/pull/11), you can also test it out.

Excellent, thanks. One more thing. I just reloaded the x98h image. When I previously loaded this image, I didn't check dmesg like I did with the other images. They had no mention of Wifi at all but this one does. It seems to start enabling wifi but then fails here rwnx_load_firmware :firmware path = /lib/firmware/aic8800_sdio/fw_patch_table_u03.bin rwnx_load_firmware: fw_patch_table_u03.bin file failed to open wrong size of firmware file aicbt_patch_table_alloc fail edit: So lib/firmware/aic8800_sdio/fw_patch_table_u03.bin does not exist which probably explains that error. I'll see if I can get my hands on that file and see if that fixes things before I worry about compiling/decompiling stuff.

@BoringName Looks right. You can decompile the dtb into a dts.. edit the dts and compile it again. You will find it in the /boot directory. dtc -I dtb -O dts -o mainline_edit.dts your_mainline_file.dtb dtc -I dts -O dtb -o modified_mainline.dtb mainline_edit.dts

Ok, just so I'm following you correctly. This line in my DTS dump bt_rst_n = <0x23 0x06 0x13 0x01>; In decimal is <35 6 19 1> In the patch you linked the line above should be matched to these values at line 293? reset-gpios = <&pio 6 13 GPIO_ACTIVE_LOW>; /* PH13 bt_rst_n */ So I should change this to reset-gpios = <&pio 6 19 GPIO_ACTIVE_HIGH>; /* PH13 bt_rst_n */ Repeat for all the other values to match the DTS dump then build the image? Is there a way to set these values at the command line without having to build an image? edit: Actually my high low flag is 0x13 which is 0001 0011. This is read from right to left isn't it? So Bit 0 is actually a 1 which means in the example above I should set it to the following? reset-gpios = <&pio 6 19 GPIO_ACTIVE_LOW>; /* PH13 bt_rst_n */ Sorry I'm probably getting in a little over my head....

Thanks. I'm at a loss too, because it works with this: 2022-04-17-ubuntu-16.04-mate-desktop-mpv-1080p-bpi-m1-m1p-r1-sd-emmc.img I was just hoping someone else might have encountered this problem. Thanks for your help though.

That is the correct one. Then I do not know anymore why yours does not work with recent Armbian images/installation.

Technically CMA is not needed at all for the VOP. Rockchip VOP has its own MMU, it is not like raspberry pi or amlogic devices. It should not require to reserve and map memory by the kernel for the VOP as long as the MMU is enabled in the device tree and it is working correctly.

Good evening. The BPI M1+ is powered via the side micro USB port. (next to the 5V SATA connector)

Which microUSB connector of the bananapi do you use for powering the bananapi itsef?

Hi, I wanted to report an issue with the currently available Armbian images for the PocketBeagle 2 (all of them from what I can tell), that stops them from booting up. I attempted to go through the bug reporting form, but it seems to only point you to the forum, so here I am. I couldn't find a location to post about the PocketBeagle 2 board specifically, so I am putting this under the Beagle Y board (they have the same maintainer listed). Please move this to the right place (or maybe create it if it doesn't exist?) or tell me how I should do this myself. The issue is in the file "/boot/extlinux/extlinux.conf", where a ".dts" file is being referenced from the directory "/boot/dtb/ti/", which contains only ".dtb" files. U-Boot fails to find the device tree file and fails to boot. Changing the file extension of the device tree in "extlinux.conf" to ".dtb" fixes the boot up issue and everything else seems to be working fine. If this is not the right place to be reporting this issue, please direct me to the correct place, so this can be brought to the attention of the appropriate maintainer. It should be a quick fix, but the images currently available to download are likely unusable for inexperienced users. Many Thanks, Paul

Hello, the SSD connected to the SATA port on the BPT M1+ works under Ubuntu 16.04 with an adapter and no external power supply. However, to rule out that as the cause, I powered the SSD externally, and it's still not recognized. So far, I've only found the Ubuntu 16.04 image that supports the SATA interface on the BPT M1+.

Thank you a lot, my Dragon Q6A now has audio

Hey just checking in. I haven't forgotten about this yet, I want to make sure everything is repeatable and possible to do on multiple versions of armbian before I write a guide and confuse a lot of people. Noticing that mpv doesn't work, I tried to do what jock suggested to Harleyyyu and update to a newer kernel version. So far... no luck. Seems like the problem boils down to having to write u-boot.bin to the eMCP before burning the actual OS onto it. I'll write again if anything goes.

If this is AW869A chip then it uses the AIC 8800 Linux Driver. My X98H TV box has a AIC8800 chip in it. https://linux-sunxi.org/Wifi#AW869A AW869A The AW869A is a highly integrated module with Dual band WiFi6 combination solution to support 1 × 1 IEEE 802.11b/g/n/ac/ax WLAN standards It uses the aic8800 firmware. A driver can be found at AIC 8800 Linux Driver. You'll need to compare the GPIO settings. Your Android dts uses HEX the mainline kernel is using DEC. https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=12 rfkill { compatible = "allwinner,sunxi-rfkill"; status = "okay"; chip_en; power_en; pinctrl-0 = <0x63>; pinctrl-names = "default"; phandle = <0xcc>; wlan { compatible = "allwinner,sunxi-wlan"; clocks = <0x0e 0x04>; clock-names = "osc32k-out"; wlan_busnum = <0x01>; wlan_power; wlan_regon = <0x23 0x06 0x12 0x00>; wlan_hostwake = <0x23 0x06 0x0f 0x00>; wakeup-source; phandle = <0xcd>; }; bt { compatible = "allwinner,sunxi-bt"; clocks = <0x0e 0x04>; clock-names = "osc32k-out"; bt_power; bt_rst_n = <0x23 0x06 0x13 0x01>; phandle = <0xce>; }; }; btlpm { compatible = "allwinner,sunxi-btlpm"; status = "okay"; uart_index = <0x01>; bt_wake = <0x23 0x06 0x11 0x00>; bt_hostwake = <0x23 0x06 0x10 0x01>; wakeup-source; phandle = <0xd0>; }; Mainline dts: https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L87-L95 https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L182-L200 https://github.com/NickAlilovic/build/blob/666dc0fabd8a284ccf50d784f6bd0bf948dd073d/patch/kernel/archive/warpme-6.12/2001-arm64-dts-allwinner-h618-add-x98h.patch#L278-L297 The specific values <0x23 0x06 0x12 0x00> generally map to: 0x23: The controller or bank ID: pinctrl@300b000 { phandle = <0x23>; 0x06: The specific GPIO pin number: In Allwinner's pinctrl driver, banks are 32 pins wide. The formula is: (Bank_Letter_Index * 32) + Pin_Number 1. The Bank Index Map Bank Index PA 0 PB 1 PC 2 PD 3 PE 4 PF 5 PG 6 PH 7 PI 8 0x12: The active-high/low flags or drive strength. In the 3-cell GPIO format used by Allwinner (sunxi), the third cell (e.g., 0x12) is a bitmask that defines the electrical properties of the pin. To decode 0x12 (which is binary 0001 0010), you break it down into bits: 1. Bitmask Breakdown for 0x12 Bit 0 (0x01): Active Polarity. 0 = Active High. 1 = Active Low (Our bit 0 is 0, so this is Active High). Bit 1 (0x02): Open Drain / Open Source. 0 = Push-Pull. 1 = Single-ended/Open-Drain (Our bit 1 is 1, so this is Open-Drain). Bit 4 (0x10): Internal Pull-up. 0 = No pull-up. 1 = Pull-up Enabled (Our bit 4 is 1, so this is Pull-up Enabled). Summary of 0x12: This pin is configured as Active High, with an Open-Drain output and an internal Pull-up resistor enabled. 0x00: Reserved or additional configuration. In Allwinner-based systems (like the H6 or H616), this value is defined in the GPIO controller's device tree binding documentation within the Linux kernel source code. The structure is documented in the kernel under Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml

@jock I figured out why the cursor doesn't show and it's not an armbian issue, the issue is more on how i implemented ffmpeg (previously Kmssink) on openauto and also the same reason why i can't use eglfs for the gui is that i had set ffmpeg to use plane 31 (primary plane, zpos 0) when streaming Android Auto. Since I am forcing the video stream directly onto the Primary Plane (Plane 31) via DRM, the hardware VOP (Video Output Processor) stops scanning out the Linux Framebuffer (/dev/fb0). This means that while Qt is still technically "running" and drawing the mouse cursor to the framebuffer in software, that buffer is simply never sent to the screen. The video stream completely overrides the UI layer. I did manage to fix it tho, since the RK322x SOCs support Tri-Plane, I had to patch ffmpeg to utilize the Cursor Plane (plane 41). Now when AA starts ffmpeg initializes the video on the Primary plane as usual, but simultaneously commits the ARGB cursor buffer to Plane 41 using the shared DRM file descriptor. This allows the VOP to hardware-composite the mouse cursor directly on top of the video stream, finally making it visible without breaking the zero-copy pipeline. As per CMA=256M, ffmpeg was throwing buffer allocation warnings. Interestingly, these warnings persist even with CMA set to 256MB—so the larger CMA didn't actually silence the logs as I initially thought. ffmpeg benchmarks actually run successfully on both 16MB and 256MB despite the warnings. However, I decided to keep the requirement at 256MB purely as a precaution. Given that a 1080p NV12 pipeline with multiple buffers can eat up memory quickly, leaving it at the default 16MB felt risky for long-term stability in a car environment, even if it 'technically' runs. PS: i haven't posted the build with the cursor patch

https://github.com/armbian/build/pull/9323

Well that was fun. Termux wouldn't load so I found an older version from 2022 thinking that version is older than the box so has a higher chance of working. That also wouldn't open until I went a bit silly and attempted to open it multiple times. Just like Mustafa in Austin Powers, once I attempted to load it 3 times in a row it would show up. Bizarre but I now have a dump of Device.DTB How do I view it properly? I opened it in notepad++ and most of it is gibberish but I can make out a few details that are a bit surprising. Namely - allwinner,h616 arm,sun50iw9p1 The label on this thing says H618 but it appears to be a H616. Where do I go to from here? Edit: I have attached the dtb file and two dumps of the file. One using fdtdump and the other using dtc. It seems the btlpm section has the same values of a device Nick referenced on page 4 of this thread. I don't know if that means anything.... Edit2: I tried "Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_xfce_desktop.img" this boots ok, ethernet works but again, no wifi/bluetooth. I'm a little surprised every image I've tried so far has mostly worked. I guess these vendors just throw together whatever parts they can get cheap but the core of the units is the same. Thanks. dtsdump.txt fdtdump.txt device.dtb