SteeMan

Per the documentation: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-login

@orlando mendez Those aren't Armbian official images. You would need to ask whomever produced those images for that information.

It this really is amlogic based, then start here: https://www.armbian.com/amlogic-s9xx-tv-box

I believe the G11 Pro has an Amlogic s905x3 processor, so moving to the appropriate forum.

I'm not sure there is a problem. It looks like this may be expected behavior. I think your board is a community supported device which means that by default it will be on the beta apt repository. There are new packages deployed to the beta apt repository daily. So depending on the settings you have for your apt updates if you have automatic updates enabled and reboot on kernel updates you will get a daily reboot. Some of this functionality for auto updates in armbian-config was just recently introduced.

moved to correct forum and added the proper tag

So good work so far. Since you don't provide specifics on what you have done (like the exact commands you are issuing in uboot to acheive your successfull boots) I can't provide specific answers. But I can provide general guidance (and it seems so far you can figure out the rest). So to get this to work from both sd and emmc and persist you need to dig into the whole mechanism some more. If you look at the contents of aml_autoscript file. This file should only need to be run once. It sets some uboot environment variables and then reboots. Those environment variable values should be persistent and should on subsequent boots change the boot flow to allow armbian to boot from sd, usb or emmc. So I'd suggest looking at your uboot environment, print out the values of the relevant variables in your environment and see what isn't set correctly, or is missing. Then try to fix. The intended boot flow is to determine sd, usb or emmc and then run the boot script s905_autoscript or emmc_autoscript accordingly which should then load u-boot.ext/u-boot.emmc and run from their whatever is configured in extlinux.conf. You said earlier that you didn't have an u-boot.emmc on your emmc boot partition, which would explain why it wasn't booting. install_aml.sh should have created that if it was run correctly. Of course u-boot.ext/u-boot.emmc are just copies of the u-boot-s9xxxxx files, so what you seem to be doing in calling them directly also works, but isn't what the scripts are expecting. I hope these pointers help you on your adventure.

There should be a uInitrd file which is the initrd.img... file converted to the uboot format. You should try that. I would recommend trying the command I posted above which chainloads the u-boot.ext file, which will then just boot from the extlinux.conf file. The u-boot.ext is a newer version of uboot that should be more compatible with a modern mainline linux image (at least that is the idea).

If you can get to the uboot prompt you can try to manually boot the system. What should be happening when you boot from emmc is that the native android uboot should run the following command: if fatload mmc 1 0x1000000 u-boot.emmc; then go 0x1000000; fi; (that command assumes that you boot partition is partition 1, the "fatload mmc 1") It should load the u-boot.emmc file in your /boot. The installation via install_aml.sh should have renamed your u-boot.ext to u-boot.emmc. Then the loaded u-boot.emmc should look for your /boot/extlinux/extlinux.conf file and boot accordingly. If you have command line uboot access you can look at your two partitions and see if they look like they contain the proper files, especially the contents of your /boot partition. The above 'if fatload...' command is just a shortcut to what should be happening. If you want to follow the whole series of logic, you start with the aml_autoscript file. This file should be loaded by u-boot when the reset button is pressed during boot. The contents of this file set some u-boot environment variables that upon subsequent boots should boot from SD, USB or emmc if they find a u-boot.ext (or u-boot.emmc) and if not continue to try to do a normal android boot. In the emmc case, the boot should run the emmc_autoscript file which contains the above 'if fatload...'. I hope this helps you explore the boot process and maybe you can figure out a way to get your box booting armbian again.

I guess I don't know what you are asking. Are you using an off the shelf USB-A to USB-A cable? Or are you building your own cable?

The only way to recover is to restore Android. The armbian builds use the Android uboot environment on emmc to boot both from SD as well as emmc. So once you copied to emmc which somehow corrupted your boot environment (which is why the instructions say to be cautious and copy to emmc at your own risk), you can't boot anything. So the only recovery is to reflash Android and start over.

I would interpret this as meaning your emmc is corrupted (as expected). You need to flash an original android firmware with usb burning tool to recover. Do you have an Android firmware for your box?

Try all the USB ports on the box (if there are more than one, only one will work). Also try with and without pressing the reset button while you are connecting. I've sometimes had to try a few times to get the right timing/combination. Bit I don't have your specific box so I can only provide general feedback.

For amlogic based boxes, you will need a usba to usba cable and use the amlogic USB Burning tool to flash an original Android firmware image for your box. You can also hookup a usb-uart connector to your box and get the uboot output which might shed some light on what is going wrong with your boot.

@Zsolt Tóth That is not an Armbian build. You should request help from where you got that code. From the devmfc readme: "What are these images NOT...They are NOT Armbian and are NOT Armbian based"

What Armbian image are you using?

These minimal/iot images are intended for expert usage and don't contain all packages you might need or want. It is assumed users of these images know what they are doing to review logs and install things that they might need.

That is new in terms of Amlogic support in mainline kernel 🙂

That is a relatively new soc. It may be a couple of years (if ever since mainline support for amlogic CPUs is poor and getting worse as most open source developers have gravitated to supporting rockchip socs) before you have something that will work for that soc.

You previously talked about this command. What is it? It appears you have run or installed something that is causing changes to your extlinux.conf file. You need to restore the contents of that file to the version that was originally installed. In your last log, in addition to your image and uinitrd being wrong, your append line is also wrong.

What do you mean by this? How are you updating the kernel? It looks like something is corrupting the contents of your extlinux.conf file.

It could be as simple as using the latest uboot source code. From you log, it looks like the shipped binaries are using uboot 2023.10.

The key thing to note is that this is a u-boot issue as it isn't even getting to the point of starting the linux kernel. The aml-s9xx-box /boot directory has instructions on how the various chainloaded uboots are built. So you can look at the uboot source code and test different things in the s905x3 uboot you are using.

Are you following the instructions on the download page? Tell us what steps you did for your install.

In your log you will see: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Armbian 25.5.0-trunk.61 bookworm 6.12.13-current-meson64 Retrieving file: /vmlinuz-6.12.13-current-meson64 Skipping l0 for failure retrieving kernel 2: Armbian 25.5.0-trunk.61 bookworm 6.12.13-current-meson64 (rescue target) Retrieving file: /vmlinuz-6.12.13-current-meson64 Skipping l0r for failure retrieving kernel EXTLINUX FAILED: continuing... 78003 bytes read in 43 ms (1.7 MiB/s) Card did not respond to voltage select! : -110 Card did not respond to voltage select! : -110 This means that uboot can't reliably read your media.