All Activity

Maybe are you experiencing the same issue ? https://forum.armbian.com/topic/56946-h3-reboot-issue/

Today I needed to reboot one of the Orange Pi which is at a remote location.... It did not come back to life.... Maybe some update removed the extraargs=reboot=warm parameter ....

No standard way to do what you want. The Armbian images from this site depend on the original android bootloader on the emmc to boot. Since you don't have working emmd these images wont boot. Theoritically if you found a working boot loader for your box and it was put on the SD card, then you would have more options.

Hello everyone, I have three Amlogic S905x TV boxes with a dead EMMC, and one with a desoldered EMMC (since I thought without it, they would boot from the microSD card). Is there a way to force them to boot into Armbian? Holding the power button doesn't work, and desoldering the EMMC didn't help either. I was able to boot Armbian using UART. A workaround is to use Ardruino, which sends commands to boot Armbian after a while, but that's a workaround, and I'd like a more elegant solution. 1) Download the *.img.gz image for the amlogic_s905x 2) Write the image to the microSD card using Rufus. 3) Connect the UART. Steps 2-6 in the brick instructions. 4) Insert the microSD card with Armbian into the console. 5) Turn on the console, close the testpoint, and at a certain point, the UART boot log will stop at gxl_p212_v1#. 6) Execute the following commands: mmc dev 1 env default -a -f;save setenv preboot 'if fatload mmc 0 1020000 aml_autoscript; then autoscr 1020000; fi; if fatload usb 0 1020000 aml_autoscript; then autoscr 1020000; fi; if fatload mmc 1 1020000 emmc_autoscript; then autoscr 1020000; fi;' save reboot Is there a simpler way to boot from a microSD card to default settings? Maybe I need to cleverly write a bootloader to it?

Hi all. I reproduced the same behaviour on my custom uboot built with enabled debugging. The problem is not solved, but I got more detailed information. It turns out spl freezes at loading main uboot loader. Here is part from logs: Jumping to U-Boot... SPL malloc() used 0x198 bytes (0 KB) image entry point: 0x4a000000 More detailed logs can be found here

If inserted, SD is booted first. If not inserted or SD read err, NOR flash is booted. NOR flash in turn boots from lower 2280 NVME. I have added boot-from-upper 2230 NVME to uboot. To install Boot via SD. Log in as root. Start armbian-install Select 7 Install to MTD Put fresh image to NVME via dd of=/dev/nvme... Eject SD, press [reset] If anything is wrong, start over with 1. Boot via SD. I am not sure wich NVME (upper or lower?) is used first. Note: If you put the same image to both NVMEs and insert SD, you may have up to three ext4 partitions with the same UUID in the box. So on reboot it is very unclear which of the three ext4 is used as root. Check with df -h /. If necessary, you can use uuidgen from uuid-runtime package and tune2fs -U as well as nano to change extlinux.conf for a different ID. HTH // Sven-Ola

Thank you! I will check later today. If there is anything else I can help about, let me know. By the way, both of my nvme drives are `Capabilities L1 PM Substates`, what is the best way to install everything there? I suppose it's not as simple as a dd of the image on them... My "low-level" skills are not what they used to be (and they were not that good in my good days), but I will check if I can build some stuff around here Thank you, and again sorry about my technical limitations

So if this works for you and you apparently know how to change bootloader, I can not really say or conclude more in addition to what is already said. I do not use images nor Imager and also do not own the ITX, I only tried to see if this issues is maybe something RK3588 generic.

Hi all, I know this is a bit of a long shot given the age of the hardware, but I’m wondering if anyone here has ever experimented with running Armbian on an EVPad 2S (the old Android TV box). I’ve been tinkering with some older devices and thought it might be interesting to see if this one can be repurposed. I’ve attached a screenshot of the system info - unfortunately, it’s pretty sparse. The box is running Android 4.4.2 with kernel version 3.4.39, but the processor type is listed as “UNKNOWN,” and I haven’t found much documentation on the chipset or board layout. so before I dive deeper I wanted to ask: Has anyone managed to get Armbian (or any Linux distro) running on it? Are there known limitations with the chipset or bootloader that make it a dead end? Any tips, resources, or even “don’t bother” experiences would be appreciated. Thanks in advance for any insights - sometimes these older boxes surprise us, but I realize support may be very limited.

Hello @brunorro. That "current.txt" from above: the UART output shows you are booting an older KY-Uboot from NOR flash. Probably SD card not fully inserted. "edge.txt" shows a correct SD card boot sequence. Best // Sven-Ola

@JuanEsf Is possible fist acces via SSH?

Hi @ff255, It's been a while, I'm assuming you are still getting the same error as mentioned below: Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... The output you shared helps, but can you share a little bit more? Would need to know the following for your case: Filesize of your kernel image file Filesize of your initrd file If possible, filesize of the DT file being loaded. With those three values, we should be able to calculate the correct load addresses and try booting. (All this also presuming that your issue is that the load addresses used by U-Boot/the bootscript do not leave enough room for either a kernel or initrd file, causing one of those to overlap the start of the other.) Groetjes,

Hello all, nice to see helios64 is still alive. I have mine and i was a bit worried about needing to switch to something else, there is not really other stuff as cool as this one. I'm using my helios64 since i go it for small it task: small webserver, xmpp server, vpn, NAS. Btrfs "raid1-like" work without issue for me an allow me to upgrade the disks one by one (it allow different sizes). The UPS shutdown mechanism stuff still work without issue. I'm thinking about upgrading it to armbian trixie to use quadlet (podman feature) on it. I just have to find the motivation. It frighten me a bit because there is very few discussion and mostly about issues in this forum.

Many thanks for your replies. @Werner I can only say that I got the image via Armbian Imager, well designed for lazy people like me. This: On the Armbian Rock5 ITX web page, There are two candidates: 1 ) This one, because it's the only image in the list with variant "Gnome": or 2) this one, because it has the same size (1.4 GB), but doesn't say anything about the variant. The two images above have two different sha hashes. If it's true that isn't good for desktop (I agree with you because it doesn't work properly), I don't understand why it's tagged as "Recommended" on Armbian Imager. Anyway, I deleted everything and started from scratch, using another image tagged as "Recommended" based on Debian 13 and CLI only. This one is less complicated and till now works. @eselarm I tried two different monitors: the first one is quite modern as it supports not only many resolutions, but also different frequencies and other stuff. The second one is very basic: it can support up to 1980p at 60hz. In both cases, I got the same behavior. I also tried in the past EDK2-UEFI, but it didn't work very well on my Rock 5 ITX due to unexpected behaviors that I could not control in an effective way. That being said, unfortunately I don't have the exact filename and sha256sum of the previous image because I changed the image.

Yes you can work to make things better. But since I don't have this box (nor even one with that specific cpu version) there isn't anything I can really help you with. But anything you find/improve can be submitted back to Armbian as a PR. This stuff is all community supported, thus it depends on people like you to make improvements and submit them back for others to benefit from.

Thanks @JuanEsf

Hi Everyone, I managed to have it booted off the SD card only without FEL fiddling (also because my A-to-A OTG cable was dumb so I've soldered a UART and get on there trying to dodge the hardcoded protected boot on eMMC by playing with u-boot and tricking it with DTB hacks forcing an internal eMMC disable in favor of SD boot.) I've ultra simplified the procedure for mere mortals: 1- Flash Pine64 Armbian image on an SD card 2- Flash the "magic 1st Magabyte" (dd brutally the first meg) 3- Insert the SD card in your Remix Mini 4- Boom The stupid part is that I've done this in a 24 hours rush and kind of tried of backtrack what I did to make it happen... I'm not able to reproduce it but I have all the notes here: https://gist.github.com/penzoiders/582bfab2c9265716dd375fb5e7679bcf if anyone of the deveolpers is interested in this I can ship to the maintainers a couple of units (I have dozens of these used-to-be-ewaste devices). I'll attach the 1M magic boot sector. remix_mini_armbian_first_1m_pine64.bin

@JuanEsf I will try !! Thanks a loot

In the meantime I fiddled with HW crypto and PCIe sleep states. While the former is working on edge and current, the latter may be an individual error with my Samsung PM9b1 128Gb NVME SSD not working in the upper 2230 M.2 on edge. While the current 6.6 kernel does not use ASPM eventually, the edge 6.18 kernel has it and it leads to read errors. Adding pcie_aspm=off to /boot/extlinux/extlinux.conf::append helped, but I think adding a "No ASPM" to pci-quirks for this device is a better solution b/c the PCIe wifi is working (has L1 and L0s sleep). So if you like then test your NVME SSDs with the edge kernel. I'am especially interested in NVMEs reporting Capabilities L1 PM Substates with lspci -v LG // Sven-Ola

Hey, thank you very much!! Downloading and testing current (did a dd on an sd card, didn't boot, I'll check it again) But edge... Boots! I have to check it with some more care so I can see how does it work And yes, the guys from Devuan make a good work keeping stuff a bit simpler. I like quite a lot Void Linux (in fact this laptop I'm writing in has it installed) I'll test current with some more care Thank you! current.txt edge.txt

1) Language. Either I expressed myself incorrectly or I was misunderstood, but my communication on this forum will most likely proceed as follows: My message in Russian -> Translator -> My message in English And the same in reverse order. 2) A little information about me. I'm a school student, so I'm unlikely to understand any of the high-tech terms. 3) AI If it helps, here's the most productive thread of conversation with Deepseek: https://chat.deepseek.com/share/20dl6vpqy97gpu4et4 4) DTBO and DTS Thanks to AI, almost every new version of dts had a new name, but they all seemed to compile to dtbo with the same name. I'm thinking of finding one that can produce a gradient, but I haven't succeeded yet, and I haven't tried everything. I don't know what color it should be, but mine was a white-to-black gradient. I'll also attach a Python script for it. I didn't create it separately, but wrote it directly into the SSH console (as far as I understand). 5) Raspberry Pi I have a primary 32 GB SD card, which I've been using since installing Klipper on my 3D printer. I also have a spare 64 GB SD card, which I installed MainsailOS, KlipperScreen, and added printer.cfg to. Initially, when I tried using ready-made libraries, I used the primary card, and even used it for a few attempts with AI. But then I switched to a second (spare) card, so that if I messed up the firmware or made any irreparable changes, I could reinstall the OS, reset it to its original state (as mentioned at the beginning), and then repeat all the necessary operations from the beginning. It's probably best to record all your steps somewhere so that after successfully setting up the screen on the spare card, you can repeat the necessary steps on the main card. Just in case, I'll save the current config.txt and all created dts files on my PC. 6) Display I'm attaching a photo of my display and another from the product page on AliExpress. I already have it soldered into the Raspberry Pi. During my attempts, I soldered from spi1 to spi0 and back maybe five times. But I'm tired of this and want to stick with the current pinout with spi1, since I have two more accelerometers on spi0, which I desoldered while setting up the display. 7) Display nuance During the first connection, I slightly damaged the solder mask of the ground plane near the positive contact of the display with a soldering iron and shorted it out with solder. I thought something on the display was broken, so I desoldered and checked some components (the microcircuit, capacitors, and resistor), but they were intact. It was only later that I discovered the real problem. After solving the problem, I connected the 5-volt power supply, but after a couple of hours, I decided to switch it to 3.3 volts just in case. I can switch it back to 5 volts if necessary. I hope this short-circuit situation didn't affect the operation in any way. If this is helpful, I've attached all the DTS versions I currently have; they can be opened in Notepad++. When I find the one that produces the gradient, I'll edit this post or write a new one. test_display.txt ili9488-debug.dts ili9488-fixed.dtbo ili9488-fixed.dts ili9488-fixed-gpio.dts ili9488-full-init.dts ili9488-priority.dts ili9488-test.dts ili9488-test-18bit.dts ili9488-test-bgr.dts ili9488-test-reg36.dts ili9488-test-rotate.dts ili9488-working.dts ili9488-xpt2046.dts ili9488-64bit.dts ili9488-correct-horizontal.dts

A long time ago, I made an armbian guide, which included adding a kernel patch. Can you try this method? "Move them* to ~/armbian-2023.05/build/userpatches/kernel/archives/sunxi-6.1 (using the scp command or sshfs)" * would mean the cpio file (use diff3 to convert to patch file**) and any linux configuration patches needed to make your initramfs. ** diff3 linux_orig_source_folder linux_source_folder_with_cpio_file https://github.com/robertojguerra/orangepi-zero-full-setup/blob/main/README2.md#73-add-the-tv-encoder-driver-to-the-linux-kernel-source

This unit on Armbian has bigger problems than the Ethernet not coming up. such as: I believe that stems from the current U-Boot being used. If I flash mine and use my DTS that comes up correctly and the ethernet. Sorry but bringing this unit up to snuff would take more time than I'm currently willing to put in right now. If a window opens up in the future, I'll look into it.

So far I only have working ethernet, which is good enough probably. So, hdmi, wifi, audio, gpu are not working. Is there anything I can do to fix any of these? Install some firmware, edit the dtb or something?

Hello @brunorro, I have uploaded two images to https://privat-in.de/ (navigate to downloads, grab Armbian*.img). Simply post findings here. The "edge" image is rather unstable, e.g. my NVME gives a read-error while working fine with "current", while a Mediatek Wifi card seems to work. Probably no easy task, could be anywhere in the IOMMU - DMA - PCIe triangle. The images are compiled from https://github.com/sven-ola/armbian-build/tree/orangepi-rv2 kernel with defaults plus switched on every Mediatek Wifi driver module. Here's my Todo for ref (+ marks ok): To be merged + Boot from SSD (upper+lower) + SPI NOR flash boot / install + SD/TF speed too slow (15mb/s) - Check SD UHS in uboot speed limit + Brcm SDIO wifi not working - Armbian edge: Brcm SDIO Wifi - Armbian edge: PCIe NVME IOErr + Bluetooth not working - RTL ethernet (2.5gbit R2V board?) - Ky overlay dtbo's missing - Focaltech touch driver from Ky? - Ky MIPI/CSI cam modules - What is that realtime r_uart? - GPU? USB2-OTG? USB3? Sound? Personal wishlist: - Device-mapper / dm_era missing + Mediatek PCIe wifi modules - PCIe adapter: Radeon GPU test Ah, yes. OpenWrt is on the Ky list of supported systems. I have a personal history on that too. While getting rid of systemd may be not that difficult (see Devuan) exchanging libc is another beast probably. LG // Sven-Ola