SteeMan

That was helpful. I can make out some of the information. What I would like you to try is to get a clearer picture/video of the information in the attached screenshot (the stuff before "Starting kernel") What I can see from this screenshot is the problem is with the kernel running, not the u-boot, I need to see the arguments that u-boot is passing to the kernel, which I can't make out from the video you sent.

I don't know. The safest would be to flash android again and install. I'm still waiting for this requested information.

@Thinvent What TV Box are you using? What build are you using (filename and where you downloaded from)?

Which ever you want (CLI = command line, i.e. server no gui; minimal = cli with minimal pre installed packages; xfce = gui desktop with xfce) I will need you to post the beginning part of the boot process you see, not the end. Also, what dtb file are you using? did you reenable multiboot? what u-boot.ext? Finally, I'm assuming the output above is from you attempting to boot 23-02 from sd card not from emmc, correct?

@nettings Moved your last post back to your original thread as I think that makes the most sense, instead of having your comments spread across two different threads.

Since I don't know what previous version you had installed in emmc (i.e. where it came from, who built it, etc). That means from my perspective you are trying to run the emmc install script on top of an unknown environment. So i'm left to guessing what your issues might be. The cleanest solution would be to flash android back to the emmc so you have a known starting point and then reinstalling the current armbian build. This assumes you have/can find a copy of android firmware for your box, or that you made a backup before you installed to emmc. If that doesn't work, I suspect the problem is that you are trying to 'reinstall' into emmc. The script is only tested for installing into a fresh environment that has android on it, not an environment that already has linux. So you may need to look at the script and only do the portions that are involved in the copying over of the files from the sd card, but omit that part that is creating the partitions and other work on the disk. To verify this is what is happening, I would need you to capture the entire output of your running of the install-aml.sh script for me to review.

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)?