laibsch

Go ahead and put that into a PR if it makes sense. That is the way to slowly improve the situation in armbian. These kinds of patches have to come from the community to be shared with everyone.

Thank you for sharing your work and insights. Please continue and don't give up!

Awesome, thank you so much for this. And it's already merged. Very nice indeed.

sounds like a genuine bug and not an error on your end. @Efe Çetin Can you confirm the issue?

It's super easy to compile your own image: "git clone https://github.com/armbian/build.git;cd build;./compile.sh" https://docs.armbian.com/Developer-Guide_Building-with-Docker/ https://docs.armbian.com/Developer-Guide_Build-Preparation/ https://www.youtube.com/watch?v=kQcEFsXEJEE FWIW, I just tried to download the two images from https://www.armbian.com/espressobin/ and did not have any issue. What problem exactly are you facing? Here's where I am being redirected to: https://github.com/armbian/os/releases/download/25.11.0-trunk.461/Armbian_25.11.0-trunk.461_Espressobin_plucky_current_6.12.57_minimal.img.xz https://github.com/armbian/os/releases/download/25.11.0-trunk.461/Armbian_25.11.0-trunk.461_Espressobin_trixie_current_6.12.57_minimal.img.xz

Wild guess: armbian-firmware or linux-firmware package?

I would assume they show up at https://www.armbian.com/espressobin/ or you can always compile your own.

Then it is time to follow http://debug.armbian.de

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

As of now, the answer is no. Same CPU means very little in terms of ease of getting it supported.

@blood Thank you for documenting your progress. I recently got hold of a Helios4 and also want to get it to boot directly off SATA. I'm currently working on getting uboot for the Helios4 updated in Armbian. Let's collaborate and maybe do the same for the Clearfog?

Mangix, are you still around? Where is the code you are referring to in openwrt? I see exactly one commit in 2020 about the Helios4 and then nothing after that. I also don't see any specific patches applied.

Have you looked into hosting your own deb package cache locally? You can set the MANAGE_ACNG build switch for that purpose and have a prepopulated apt-cacher-ng proxy in your LAN. Let us know how it goes.

In my opinion and experience, armbian-config is a horrible pile of hacks that are almost guaranteed to eventually eat your data. As such, in my opinion the only sane action is to stay far clear of it.

Please prepend the commands with LC_ALL=C like "LC_ALL=C apt update" and post the output again.

ping @metalhard

Thank you for that patch. Do you know how to use git and github? You don't necessarily need to open an issue first. You can go straight to pushing a PR. Just explain yourself enough so that a reviewer who may not understand your board can see why your patch should be merged in.

I am not exactly sure what you are trying to do, but maybe the solaar or logiops package can help you achieve your goal.

Thank you for your quick answer, Jimbolaya. Yes, I did try different cables all with the same result. I wonder if there is another way to access the serial console, J13 perhaps? Albeit with some required soldering, I suppose. Then remains the question of which headers exactly relate to GND, TX and RX.

I received a Helios4 and was finally able to get it to boot. As per instructions, I booted from microSD and flashed the latest Armbian image to sda1 via the nand-sata-install command. This reboots fine now, but only with the microSD-card present and the SW1 dipswitch set to "SD card boot mode". Is anybody here using "SPI NOR Flash" or "SATA1" boot mode to get rid of the microSD card? I am bit handicapped here since my serial port on the microUSB only comes up maybe 1 in 10 times. I wonder if it's worn out or if I am simply doing something wrong. Related Links: 1 2 3 4

Thank you for the nudge. But who are you nudging? It isn't up to the PR author (me) to get this accepted. It's been rotting away since nobody actually tested it. And that could only be done by people who have the device, including @The Tall Man, I believe or others. I do not have access to the device(s) in question. And then one of the other devs needs to accept it. I'm happy to rebase or respond to reviews, but that hadn't happened, so we are now going in circles. So, the question is really who you are nudging.

Thank you for that additional information, Igor. The lack of desktop images is only a minor inconvenience, I'd say. Easy enough to install the required packages after installation of the base image to the SBC itself.

We support Armbian software but not random software from the internet. RKdevtool is as far as I know a tool from Radxa, not Armbian, either. CPU boxes are cheap and cheap for a reason. Nobody really supports them. We give some very limited community support here. With your current random software this is not the right spot for you. Best of luck to you.

I retried that image now but with a different installation method, booting into OOWOW (?) via the Function+Reset button, control via serial debug console. I then wget the image from my local server and dd out to /dev/mmcblock0. Subsequent boot was indeed successful.

Thank you, @c0rnelius. I might do that. But I believe that in fact, the images are faulty (and hence should be replaced). Can you confirm to boot successfully from any of the ones I marked as broken?