All Activity

Thanks! Just run upgrade to 6.12.30 - and sounds works! (on 6.12.20 was no sound card in aplay -l )

I set up an Ubuntu VM on my Mac to do linux stuff. With that I edited the ambianEnv.txt as you said. Behavior is the same. I should also add that there is a regular double-blink of the System LED after the initial fans (of about 2-3 seconds). I now remember that back when I set up the Helios, I was told to use PuTTY on Windows instead of my mac. Maybe there's an incompatibility of some sort? I checked and they recommend a set of drivers for Mac that I hadn't installed. I did and after playing around -- and only occasionally while playing around with connecting, disconnecting, rebooting -- did I sometimes get some garbled output in the serial window: posting it because it's the longest and least garbled output I've gotten so far. The command was exactly as on the Helios64 website, i.e. the baud rate was correct. Not sure where to go from here and what to blame.

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.