SteeMan

moved thread to the correct forum and modified title to include the box name

I don't understand your last post. You mention 20.10, but the current builds are 23.02 and that is what you should be downloading from the link I posted above. You say "now it starts, however..." what version are you saying starts? Your original post talks about an ancient 5.88 build and the link I sent you is for 23.02. I don't know where 20.10 is coming from.

I don't have this hardware, so I'm just going to make some basic debugging suggestions. Have you tried a 5.19 kernel from the most current release? Or even a 6.x nightly edge build? Do you have the same boot loader installed on both boards (uart output of each boot) Also armbianmonitor output is always helpful.

Where did you download this build from? It doesn't look like a build that originated from armbian. What tutorial?

What build (exact file name) and download location did you have installed? This file you mention isn't anything I am familiar with, thus I would like to know where it came from.

The download link is in the instructions linked to above

How are you doing the update/upgrade? command line or gui? The error screen you show above is interesting as it is saying it can't find the mmcblk1p1 (which should be the root partition on the sd card). Can you provide a directory listing of the contents of /boot after the upgrade, but before rebooting. Also could you show the contents of your extlinux.conf file (again after upgrade but before rebooting). Then it would also be helpful to have the full contents of the uboot display during the reboot (not just the end of the output you have screenshot above).

That build is over three years old. Please try a new build per:

You have provided very little basic information about your situation. Lets start with the basics: What box do you have, what dtb are you using, what u-boot.ext are you using. Did the box originally work from the sdcard? What exact steps did you do between when it was working and when you get the error above?

@Igor Thanks for that info, I was able to track down what was the cause. I will have some additional questions when I get time to attempt a fix.

I was doing some testing today on aml-s9xx-box builds and noticed that with meson64-current (6.0.13) kernels the boot logo is showing, but with meson64-edge (6.1.0) kernels it does not. I know there was a recent commit that probably is causing this, something about removing the old way of handling boot logos. So my question is, what needs to change to convert to the new way? I suspect it has something to do with the append line that the build process is inserting into the extlinux.conf file: append root=UUID=0ffde9aa-5a6a-4d6f-bbef-0d8daf439537 rw no_console_suspend c onsoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 bootsplash.bootfile=boo tsplash.armbian

Could you provide more information on what is happening when you try to boot? The only info you have provided is when you tried with the distributions from the other site (which is meaningless for what you are trying now with the official armbian community builds). Simply saying "I have been unable to sucessfully boot" doesn't provide us much information to help you with. Also, what dtbs have you tried?

@st0rk

@st0rk try using a recent build. I haven't seen this issue on recent kernels. But I did previously see the problem with the 5.9 build.

moved post to correct forum

nand support only exists in legacy vendor kernels. Mainline linux does not have such support. Armbian is focused on bringing mainline linux to all sorts of devices so that users have access to currently supported code. If you think about what you are asking for, you are asking for a linux kernel that is at least 8 years old and has never received any security or other patches. Why would you want to run with a kernel that has likely hundreds of known security vulnerabilities in it?

Moved to correct forum

@trev1no2 What you are trying to do is possible, but it is likely to be a lot of work. You can't just take a kernel built to support one cpu/board and expect it to run on another board. That is why for example Armbian needs to build 20+ different kernels to support the variety of cpu/boards that Armbian can run on. So a kernel built for a RPi won't simply run on a Jetson Nano. You say you have tried to build the image on the Nano running Armbian. What version of Armbian? Since you are trying to build this, I'm assuming this 'patched kernel' you are talking about is a series of source code patches that you are trying to apply on top of a specific kernel version (apparently 5.4 in your case). One problem is that the 5.4 kernel is 3 years old and Armbian has moved on to more recent kernels. So you will either need to port your patches to the more current kernels armbian supports, or get a 5.4 kernel working on your board. If you go down the 5.4 route, then your first step would be to get a generic 5.4 kernel working on your board (i.e. don't worry about the patches yet, just see if you can build a 5.4 kernel that you can get running on your board). Once you have that working then you can deal with patching your kernel with your patches. However, my recommendation would be to not try to going with a 5.4 kernel, but porting the patches to the current Armbian kernel and using the Armbian build framework to build your kernel.

What version do you have installed (please provide the full name of the image you downloaded to install)?

@hexdump Thanks for that link. I just read through the whole thread and this other one that is referenced therein (https://forum.armbian.com/topic/18902-s905-failed-to-boot-from-emmc). It is clear that no one has been able to work around the fact that the mbr info is incompatible with the android uboot on the s905 based on all the smart people that have looked at the problem. The workaround that @pista used is the best out there, but because it directly writes the boot files (kernel, etc) to emmc, it isn't a good solution IMHO as it is not compatible with a standard apt update of the kernel (which the new aml-s9xx-box builds support) I have found that the "op hub" fork perhaps has found a solution by using the ampart tool (https://github.com/7Ji/ampart) Since I don't have an s905 box, I really can't do much. And since the s905 boxes are by now ancient it isn't really worth my time to get one and go down this rabbit hole. However I do plan to remove from the aml-s9xx-box builds the install-aml-s905-emmc.sh script as I don't see how as written it can ever work and update the install instructions accordingly.

sid is the Debian distro and kinetic is the Ubuntu distro

Please read the TV Box FAQ post: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first (wifi isn't going to work on most amlogic tv boxes and no one is working on that, but this is a community project so code submissions are welcome)

moved post to separate topic

Have you tried any other dtb files? Per the instructions you should try all of the dtbs for your cpu type hoping to find one that works the best. Also 15-30 seconds is too long. Try 5 seconds and then 10 seconds. Also what happens when you power the box both with and without the sd card inserted (not using the reset button for either). Installing multiboot (what happens when you press the reset button with the sd card is inserted) is something that only needs to be done once. Before a successful install of multiboot the box will always boot to android (with or without the sd card installed). However after multiboot is enabled, then the box will boot to android without the sd card, and attempt to boot from the sd card if it is present and not boot android.

So I have been looking at the two scripts in /root (install-aml.sh and install-aml-s905-emmc.sh). Basically the only difference between the two is that s905 version assumes that p0 and p1 exist, where the other version creates the partitions. Since I didn't author these scripts (but now find myself maintaining them), I don't know why this difference exists in the scripts. And since I don't have an s905 box, I've never been able to test the s905 version. Since you seem to have an s905 box that doesn't have the partitions that the one script expects, you could try to run install-aml.sh instead. It seems you have the ability to restore the andoid image if necessary. So unless you really brick the box hard, you should be able to recover if the other script doesn't work.