Jump to content

SteeMan

Moderators
  • Posts

    1774
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

Recent Profile Visitors

13015 profile views
  1. You are using the minimal image which as the name implies has the bare minimum set of packages installed.
  2. The appropriate place for this question is in the existing thread for rk3328 tv boxes:
  3. Per the documentation: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-login
  4. @orlando mendez Those aren't Armbian official images. You would need to ask whomever produced those images for that information.
  5. It this really is amlogic based, then start here: https://www.armbian.com/amlogic-s9xx-tv-box
  6. I believe the G11 Pro has an Amlogic s905x3 processor, so moving to the appropriate forum.
  7. 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.
  8. moved to correct forum and added the proper tag
  9. 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.
  10. 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).
  11. 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.
  12. 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?
  13. 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.
  14. 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?
  15. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines