All Activity

Replying to my own again...UEFI doesn't seem to boot from SD if you don't modify the HW, it does boot from the internal MMC, though! All you need to do is flash the EDK2/UEFI bios (1.1 at the point of writing) to the internal MMC and then fix the GPT (I just run GParted or KDE Partition Manager - that asks you a couple of questions and fixes the parition table). After that you can just run the e.g. Fedora Rawhide ARM64 iso and install to the same SD (just have the installer "add the OS"). After that you can boot from USB, SD, NVME and even a SATA with a m2 sata adapter.

Replying to my own post. ... EDK2 has an UEFI BIOS which runs mainline linux - no custom builds. It supports ACPI and device tree. I run this now with Fedora Rawhide 43 with KDE (6.4 Beta) which runs ACPI out of the box, older kernels work with device tree. I haven't used the latest mainline Armbian but that should work, too (at least the latest mainline image). Rawhide runs mainline kernel 6.15/6.16 (latest build) which supports the SOC + GPU out of the box.

The analog audio output to the connector that is soldered to the board does not work for some reason. Although there is a code in the core, there is also a node in the DTS.

Audio output via HDMI should work on all H616-H618 devices. This was tested on the bananapi-m4-berry board for current and edge kernels. In the pulseaudio settings applet, you need to make several switches back and forth (turn on/off) for the sound to appear. Tested on gnome, ubuntu.

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

Testing the M2 16G with trunk 90 (Kernel 61.15) & trunk 38 (Kern 6.14.8) and the USB-C OTG port isn't working. [ +0.245948] usb 7-1: new full-speed USB device number 2 using xhci-hcd [ +0.124258] usb 7-1: device descriptor read/64, error -71 [ +0.227984] usb 7-1: device descriptor read/64, error -71 [ +0.223715] usb 7-1: new full-speed USB device number 3 using xhci-hcd [ +0.124295] usb 7-1: device descriptor read/64, error -71 [ +0.223803] usb 7-1: device descriptor read/64, error -71 [ +0.104107] usb usb7-port1: attempt power cycle [ +0.395844] usb 7-1: new full-speed USB device number 4 using xhci-hcd [ +0.000112] usb 7-1: Device not responding to setup address. [ +0.203891] usb 7-1: Device not responding to setup address. [ +0.203946] usb 7-1: device not accepting address 4, error -71 [ +0.000609] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.119353] usb 7-1: new full-speed USB device number 5 using xhci-hcd [ +0.000118] usb 7-1: Device not responding to setup address. [ +0.204373] usb 7-1: Device not responding to setup address. [ +0.207473] usb 7-1: device not accepting address 5, error -71 [ +0.000613] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.000109] usb usb7-port1: unable to enumerate USB device [ +30.217458] usb 7-1: new full-speed USB device number 6 using xhci-hcd [ +0.123993] usb 7-1: device descriptor read/64, error -71 [ +0.231951] usb 7-1: device descriptor read/64, error -71 [ +0.223935] usb 7-1: new full-speed USB device number 7 using xhci-hcd [ +0.120028] usb 7-1: device descriptor read/64, error -71 [ +0.224108] usb 7-1: device descriptor read/64, error -71 [ +0.103939] usb usb7-port1: attempt power cycle [ +0.396008] usb 7-1: new full-speed USB device number 8 using xhci-hcd [ +0.000139] usb 7-1: Device not responding to setup address. [ +0.203807] usb 7-1: Device not responding to setup address. [ +0.207853] usb 7-1: device not accepting address 8, error -71 [ +0.000608] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.119394] usb 7-1: new full-speed USB device number 9 using xhci-hcd [ +0.000140] usb 7-1: Device not responding to setup address. [ +0.204031] usb 7-1: Device not responding to setup address. [ +0.203926] usb 7-1: device not accepting address 9, error -71 [ +0.000796] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.000293] usb usb7-port1: unable to enumerate USB device [Jun 2 19:50] usb 7-1: new full-speed USB device number 10 using xhci-hcd [ +0.123926] usb 7-1: device descriptor read/64, error -71 [ +0.116517] xhci-hcd xhci-hcd.7.auto: remove, state 4 [ +0.000011] usb usb8: USB disconnect, device number 1 [ +0.000280] xhci-hcd xhci-hcd.7.auto: USB bus 8 deregistered [ +0.000009] xhci-hcd xhci-hcd.7.auto: remove, state 1 [ +0.000004] usb usb7: USB disconnect, device number 1 [ +0.055430] usb usb7-port1: attempt power cycle Same USB-C device (CCD camera) tested and working in the USB-3 port.

First of all, I would like to thank the developers for making this possible. I have two MXQs, one with OMV and the other running raspotify with a DAC. Thank you very much, it was a great addition to my homelab. I noticed that docker container support for armhf has been discontinued over time. Does anyone have a list of docker images for armhf?

The 25.5.1 kernels seem to have landed in the APT repos. I can confirm that at least the `current` kernel now has networking working as intended. I haven't checked the legacy kernel whether it works enough for a semi reasonable upgrade path. But I'll see that once I get to upgrade the other CB1 boards I have.

Is there any news for HDMI audio on this board?

I haven't tested these functions, I don't know if it works or not. https://docs.armbian.com/User-Guide_Getting-Started/#first-login

@Werner NVME, sorry...

https://docs.armbian.com/User-Guide_Board-Support-Rules/ support a whole soc family would be impossible. For example a vendor could do a poor implementation of something which could never work but we "support" it and people complain why it doesn't but there would be literally nothing we could do about.

Hi ssd or nvme? Both needs different handling kernel? edge? vendor? current?

Upgrade to 25.5.1 successful (straight-forward).

Thanks for your answer 🙂 Thats what I'm also not understand .... You (premium) support the radxa 5B or so, it has exactly the same Chip .... what does this exactly mean ? And you are completely right, the SOC world looks like so depressing, regarding the gap between the promises of the SOC producers and what you really can use .... 🙂

G’day guys, just grabbed a version of Armbian again to play around with on an orange Pi 5 I have had for a while. I have installed the latest stable (25.5.1 Noble Gnome). Everything went smoothly, and I have a 512GB ssd on the board, so I went through the install process using armbian-install. I managed to get the OS installed on the SSD, but when I went to install the bootloader, I got some error messages saying that the SPI image was not chosen. I followed the process for erasing the MTD, but still I got error messages relating to no spi image. I tried to boot from the ssd and just got a black screen. I downloaded Joshua Riek’s Ubuntu 24.04 distro and booted it from the sd card and ran his command “sudo u-boot-install-mtd”. It installed to the MTD and then I shut down and removed the sd card and booted up. Armbian has now booted from the SSD with no issues. I couldn’t find anything on the forum so I thought I would post this to assist anyone else who has this issue. If the guys at Armbian have any thoughts on why this may have happened please let me know.

https://askubuntu.com/questions/1371732/what-is-the-purpose-of-cgroup-enable-cpuset-cgroup-enable-memory-cgroup-memory-1 Without further research the answer here mentions that the flags in question may be specific for RaspberryPi, hence won't work on other kernels/boards.

All images are specifically made for the board. Some share the same kernel package since they are from the same soc family (for example, there are a lot of boards using the rk3588/s soc so they can have the same kernel package. Board's components are defined in device tree). Sample board config: https://github.com/armbian/build/blob/main/config/boards/orangepi5pro.csc BOARD_FAMILY is rockchip-r3588 The sources config: https://github.com/armbian/build/blob/main/config/sources/families/rockchip-rk3588.conf Pro, max and ultra are community contributions and for now entirely unsupported since there is also no support from the vendor for us for these whatsoever to make its software better.

Hi there, Some notes from my side, with the image we are now both trying out, I do have some issues every other boot. Seems that the kernel gets stuck at: [ 19.941334] amba ff6d0000.dma-controller: deferred probe pending: (reason unknown) [ 19.942069] amba ff6e0000.dma-controller: deferred probe pending: (reason unknown) [ 19.942765] platform ff1d0000.spi: deferred probe pending: (reason unknown) [ 19.943404] platform ff1e0000.spi: deferred probe pending: (reason unknown) [ 19.944042] platform ff200000.spi: deferred probe pending: (reason unknown) No idea why. This seems to alternate every other boot, so after a reboot this appears to be tolerated, but the next reboot the kernel gets stuck again. And stuck in like magic sysrq stops working. Make sure you have verbosity=8 in your armbianEnv.txt, to make sure some (read: more) output is generated on the console. Groetjes,

Right to clarify what I described earlier was the patch creation process, where you would modify an existing file or if the file does not exist you would create in the relevant. After running for a bit the build process will pause. At this point you would need to open a new tab and navigate to cache/sources/linux-kernel-worktree/6.12__sunxi__armhf/arch/arm/boot/dts/allwinner. Here you would need to amend the sun4i-a10-topwise-a721.dts. According to the dts it already has the panel node so the on board display should at least work unless the driver is broken or device tree bindings have changed. Unfortunately I havent worked with panels so cannot provide much further assistance for other than confirming that an entry exist in the simple panel driver. sudo modinfo panel-simple | grep starry [sudo] password for ryan: alias: of:N*T*Cstarry,kr070pe2tC* alias: of:N*T*Cstarry,kr070pe2t ryan@pcduino2-1:~$ Normally to get hdmi to work you simply have to enable the hdmi nodes plus create a hdmi connector node. I have attached the patch that I use on my pcduino2, applying the same alterations to the dts of the topwise's dts should work. I have had issues with hdmi display in 6.12 which I found a work around for but not perfect as we have to modify the hdmi driver. From What I can tell the problem is related to atomic check function: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ It may be fixed in kernel 6.14 but I havent tested it yet. save the changes in your text editor and exit. Return to the tab running the build script, hit enter and it will generate a preview of the changes and ask if you are happy with the changes or not. type 'y' to accept. Luckily the build process will helpfully walk you through these steps. Once the build process has finished go to output/patch/. and rename the newly generated patch something useful so that you remember its purpose. Then move it into patches or userpatches. Which is up to you but personally, I prefer to have my patches in userpatches unless it is something I plan to merge in future. whenever you run git pull to fetch the latest version of armbian build, the patch directory is likely to be updated whereas userpatches is not affected. A caveat with userpatches is that full directory structure is not pre-existing so you have to manually create it, mirroring the patches directory. Also note that userpatches are applied after patches in the patch directory. Did you clone Armbian build directly or are you work off your own fork? Now what i tend to do is rerun the build process to check that the patch was applied successful. So rerun ./compile.sh BOARD=topwise-A721 (Replace with the name used in your config file) BRANCH=current RELEASE=bookworm kernel-patch. if successful it should appear in the list of patches and if applied under usepatches it will helpful be the last entry on the list. Unless you have any further patches to apply you can then go on to running a full build. I am suprised no one has yet done a video on the patching process yet Have you attempted disassembling the tablet to check for any solder pads present which could be the serial console? If there is then it may be possible to hook up a usb to serial converter. This could at least be a solid indicator to confirm that the device is at least booting. best of luck Ryzer pcduino2-hdmi-enable.patch

baudrate: indeed at 1500000 The serial actually did not work before. Back when I first installed the Helios I used a C-A cable. Now I gave it a try with one and it improved the behavior: instead of appearing and disappearing, the usbserial device is now constant. The issue is just that nothing is shown via `screen`. I think I'll try by inserting a HDD because of what you said. I remember the USB-C cable issue. To be sure, I had removed a sliver of plastic using a cutter just like I did a couple years ago. No issues with clarity, I know about that quirk of the Helios. But yeah, this was not the issue now as I only worked with "modified" USB-C connectors. I unmounted the "disk" (SD card) before working with it. That should be safe as nothing tried mounting it afterward. Was the whole thing written: The `dd` command finished and balena Etcher even confirmed that the Flash was complete. So I think this is also a yes. conv=fsync: No I did not do this. Repeating the whole procedure with this and then after reinserting, I'll get a sha256sum of the contents… It worked, the resulting sha256sum is identical. Just trying to boot the machine again… Same behavior, sadly. HDD not yet inserted btw, will do that tomorrow.

Hi, Just to baseline some stuff: The baudrate you use in screen, it's set to 1.500.000 ? Did the serial cable work before? Or is this the first time you use a C-C cable? I know too little about the differences of C-C vs A-C cables, but if this is the first time using the C-C cable, please try to use A-C with some Mac-to-A hub. I can only confirm an A-C cable works here. Are you sure that the connector of the C end at the Helios64 side is making proper contact? In my (and other's case) the actual plug part did not fully pass through the case. I had to cut some of the plastic away of the C side to expose more of the actual connector. This way it fully entered the case and made better contact with the board. Not sure if I'm explaining this well or not, let me know if this is not clear. Is there anything on your Mac side that is trying to automatically mount the card while you are writing the image? Are you sure the entire image was written to the SDcard? e.g. Did you use conv=fsync for dd ? Or a sync before removing the SDcard? (There is no umounting happening as the card could not be mounted you mentioned.) Did you try and sha256 sum the SDcard contents as well? You should be able to do that (slowly) with dd if=/dev/sdcard bs=1 count=$(stat -c '%s' Bookworm_current_minimal) | sha256sum Make sure to remove the card first and reinsert it to avoid dd is reading cache. Grt,

Just a short update to say that I also tried the balena Etcher with no changed behavior.

Hi, The output of `parted [.img file] unit s print` is: I'm on macOS, which isn't able to read ext4. Mounting didn't work at all. I also tried with a Debian image via docker but the mount command was not permitted (even with using sudo). The only other Linux machine I have is a Steam Deck, which I might be able to use in Desktop mode for this. I did run sha256sum on the downloaded file and checked with the hash on the Armbian page. Afterwards just ran `xz` and `dd`. I repeated this on a different machine (also macOS) and the outcome still the same. EDIT: Oh you meant for me to run sha256sum on the unxz'd file, so the .img file directly. The checksum is indeed the same as what you posted. I do agree that it seems like the SDcard and/or image are at fault. I tested two different power cables on two different Helios64 machines, it kind of has to be this. But what else could I try? The USB-C cable I use to get access via `screen` is USB-C to USB-C and is confirmed to be for data&charge. I saw that the Helios64 documentation says to use USB-C to USB-A but I doubt that this is the reason for the flaky connection. It does seem like an issue with the Helios64.

Great, so I used the config file provided in the previous post that I quoted, with a small change: I replaced "LINUXFAMILY" with "BOARDFAMILY". Am I to place patches to the kernel and u-boot inside userpatches? When in the build process should I do that? U-boot does work currently, and the original problem when I try to boot is that after "Starting Kernel..." I have nothing visible over HDMI or on the on board display (Or no way to check that I know of if anything is working). What I understand currently is that since U-boot works, I need to first provide a dts file that makes the display work, and then configure armbian build script to use that dts file, is that the way to go? On linux-sunxi mailing list I was told that the display on this works with the simple panel driver using the "starry kr070pe2t" entry. At this point I am not sure what the immediate next step should be. Thank you!