All Activity

The only way, which is really discouraged and discontinued, is to use a build with legacy kernel. On mainline kernel, the only driver supported is for ssv6051p, but it does not work for ssv6256p. There could be several reasons the eMMC is not detected. One of the reason is obviously it is the broken, even though the DDR part is still working. More often the board has some circuitry or the chip has some configuration that need to be tuned properly in software to work. Tv boxes have plenty and plenty of different configurations that is impossibile to cover all the compatibility issues that may arise. If the flash part of the eMCP is really broken, if you plug an sdcard with Armbian on it, the stock Android should not boot (obvious if the internal flash is broken) and Armbian should boot instead. About the MSN8800D, it seems to be a clone of AIC8800D chip, of which a driver is circulating and should already be integrated in armbian, but not yet enabled for rk322x.

@Heisath Nice to have you back. I know everyone is busy ... I think speed of this has been brought down in past year and most of changes were on the "must be done" list. Changes generate stress, regardless of their intention. It is getting more and more troublesome - big complexity vs. new devices keep coming out light-speed vs. limited resources for maintaining. We have little to fight this Freshly build image from your patch - doesn't work for me - what I am missing here?

Hello @Domas, are you still trying to achieve this? You are obviously stuck in the middle now, in the twilight zone. I am fairly sure, you can still recover from this. We should first understand better ; Can you give me the output of "aptitude search '~o'" and "apt-cache policy | grep http | awk '{print $2" "$3}' | sort -u"? The way I read what is happening to you is that do-release-upgrade is trying to upgrade ports.ubuntu.com entries, fails, tries to fall back to archive.ubuntu.com but fails with that, too, because there are no armhf packages published, there. Not sure, if that qualifies as a bug in do-release-upgrade. Probably not. PS: Apart from the upgrade issue, you also seem to have an issue with filesystem corruption (lines 608 and 637 to 639 of https://paste.armbian.com/oletimumob). The ability to detect and fix these kind of issues with a live-mounted FS is one of the many reasons I switched to btrfs from ext4 a long time ago.

Please read first page , its very very hard to brick the board normaly insert sd-card and flash another image and you good to go please provide serial log if possible , else we cannot see where th problem occur

@Nick A It works perfectly now. Thanks a ton!

@Nick A It works perfectly now. Thanks a ton!

@Nick A It works perfectly now. Thanks a ton

Thank you for reporting back. Glad you got it solved.

This. Just use the tools that were intended for software installation.

I suggest you simply try. What is holding you back?

Thank you for your question, @Jacob Burckhardt I do not use tags and FWIW, I do not see them on my main laptop, running Ubuntu Noble, either. Is this a Debian thing? Is your Armbian user space Debian?

It seems this has already been figured out. No issue...

Thank you for coming back and sharing your "solution". It is always good to hear when things work out in the end, no matter the reason.

Att, my board broken after trying to update, idk why but it crashes and system doenst start i have installed the last trunk.

Hello everyone, I have a problem, I hope you can help me. I have a TV box sold here in Brazil that has an H316 processor. I tried to use the images that were made available, but I only managed to boot successfully when I compiled my own after downloading the build from Git. Now I can boot from the SD card, create a user and passwords, use the sudo armbian-install command, but after that, a message appears saying "Counting files... few seconds" and freezes on that screen. Could someone tell me what I can change in the img compilation to fix this?

Hi @Heisath, I think i can make a pull request from here: https://github.com/armbian/build/compare/main...djurny:build:patch-1, but would like to see someone else besides me test and scrutinize change. If positive results are in, I would very happy to finally contribute something! Groetjes,

I am still here but as we all know our time is precious and I am currently using all my time for other projects. So I am not currently maintaining this board. On the whole I think armbian is moving too fast, for me, with new features in the build system and kernel which has somewhat discouraged me from further investing my time. ARM is IMHO not a stable platform, unfortunately. @djurny solution looks good - I might test this later and try to integrate it. But everyone else, if you can, please make it a PR on github It should only be necessary to adjust this file https://github.com/armbian/build/blob/main/config/bootscripts/boot-mvebu.cmd

installations

Is this an error in the build or installing jammy?

The directory is incorrectly specified

Try again with Linux 6.10 or older if you have an armbian img. Two things I found needed for linux 6.12+: 1. Define the pinctrl-names and pinctrl-0 parameters 2. MAYBE: rebuild Armbian in your computer, with one less Armbian patch As seen in: https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/#findComment-216779 In this thread, you can see how I detected miscofigurations of the SPI GPIO: https://forum.armbian.com/topic/50418-dont-use-kernel-61216-on-sunxi64/page/2/#findComment-216924 WDR_s: did you try upgrading to Linux 6.12? (you could get H264 acceleration if you upgrade)

What’s the error this time?

Hi all, @Igor @0r31 I managed to come up with a more structural solution that should work for future increased sizes of the kernel/inital ramdisk as well. Let me know if you are interested in testing this out before I attempt to make a pull request, as some instructions are required to test this out. Changes are all in `boot.cmd` so no rebuilding or updating of U-Boot required. Based on the load addresses in U-Boot, reshuffled the loading of DT, kernel and initial ramdisk last. After loading the DT it will calculate the kernel load address based on the DT `totalsize`. After loading the kernel it will calcuiate the initial ramdisk load address based on the kernel filesize. Some other minor changes are also incorporated; `fdt resize <extrasize>` adter re-loading original DT when applying the overlays has failed. Skip the `fdt apply` and `fdt resize` for the SPI-SATA workaround. Results on my Helios4 with an old U-Boot 2018.11 below: Comments are welcome, Groetjes, boot-mvebu.cmd

it didn't help, it threw up errors

Thanks for investigating this. I have seen this issue reported quite a bit recently. I assumed it was something that had changed at the dtb level. Knowing this helps provide guidance to others in the same situation.