Jump to content

SteeMan

Moderators
  • Posts

    1365
  • Joined

  • Last visited

Posts posted by SteeMan

  1. 7 hours ago, Bokies said:

    I can paste the "env print" or whatever i can get to from u-boot (or maybe from the 5.44 armbian) if that can tell us anything useful ..

    Yes this would be useful.  So you have a serial cable soldered to the board so you can interact with the u-boot process from a terminal?  The issue (as I suspect) is all about the u-boot environment variables that are stored on the emmc.  These are what get changed by the 'multiboot' processes that the other firmwares setup.  If you look at any distribution you have for amlogic boxes where will be a file aml_autoscript that gets run when you use the toothpick method or android update method.  All that script does is set u-boot environment variables that get stored on emmc.  Different distros do their multiboot differently and it has changed over time and there are incompatibilities in how different groups have done things.

     

    7 hours ago, Bokies said:

    or even just wipe that part altogether ..since booting via usb and sd will write their own stuff there on each instance

    This will brick your box.  The thing about amlogic based boxes that makes them difficult to work with, is that the boot process basically only looks for u-boot on emmc.  So you are always running the u-boot shipped with android.  The 'multiboot' hacks are about tricking u-boot to use other media, but the tricks all involve starting with running the original u-boot from android.  Thus if you mess with the emmc partitions that contain the android u-boot and its required files, you brick your box.  So the boot process is essentially run the native android u-boot and hope that it is capable of launching a different more modern kernel that exists on sdcard/usb.

  2. You have a mixture of true and untrue statements in your description above.  Part of that is due to the fact that you are working with different builds that do things differently.  I can only speak to the armbian builds balbes150 produced as that is all that I am familiar with. 

    14 hours ago, Sameer9793 said:

    havent figured out what the s905_autoscript and , emmc_autoscript exactly does yet but iam pretty sure boot.ini loads the u-boot.ext file (i might be wrong).

    It is key for you to understand what these s905_autoscript and emmc_autoscript files are doing at that is the heart of how the boot process determines what to load.  The first incorrect statement is with regards to boot.ini.  The balbes150 builds do not use this file.  While it may exist, and is used in other armbian builds, it isn't used by the balbes150 builds.  (It took me a long time to figure that out).

    When multiboot is installed (i.e. the toothpick method or update android app) the aml_autoscript file is run.  All this file does is set u-boot environment variables and then reboots.  These u-boot environment variables are stored on emmc and the original android u-boot installed on emmc runs and then based on these variables will conditionally load s905_autoscript or emmc_autoscript based on the medium which will then chainload the u-boot.ext uboot.  These u-boot.ext files as mentioned above are the work of hexdump (and balbes150).  Here is a link to a thread that goes into hexdumps work.  The first post of this thread has links to hexdumps git sources for the s905x and s905x2 u-boot builds.  (https://forum.armbian.com/topic/16753-chainloaded-uboot-images-for-amlogic/)  I have in the past been able to rebuild from source the u-boot.ext's distributed in the balbes150 builds using this info.    Also the format of the *_autoscript files are u-boot script files.  There is a u-boot utility that converts a text file to a u-boot script formatted file.  The u-boot script files have some binary bytes that simply surround the original text file, so you can look at the script files and see the source contained within them.

     

  3. The multiboot mechanism (what gets installed/setup when you use the toothpick method), sets certain u-boot variables on the emmc storage of your device.  So the boot process is that you are using the original android firmware u-boot, which then chainloads the u-boot.ext file on your sdcard/usb drive.  The nature of what settings get installed in the emmc storage have changed over time.  I suspect that what is happening is that you have previously installed a set of u-boot variables on your emmc that is incompatible with what is trying to be installed/used in the later build you are now attempting to install.

    The reason I believe this is your problem is that you seem to have a strange mixture of environment variables that are causing the boot process to load things one would not expect it to be loading.

    What I would recommend is that you reinstall a clean environment (i.e. reload an android firmware) which will reset everything to a known state and then try installing multiboot through the toothpick method using the 20.10 build.

  4. The last balbes150 images for amlogic can be found in the FAQ instructions for amlogic installs: https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus

     

    As for the kernel boot command line, I have never needed to change anything on that line so I don't have any clue on where to get more information.  However, since I have never needed to know those specifics, I would suggest that isn't something you need to dig into as you are learning the boot process.

    Here are my suggestions on what you start to look at:

    aml_autoscript and aml_autoscript.zip  - These are what enable 'multiboot'

    Understand how u-boot environment variable work to control the boot process

    Then move onto the s905_autoscript and emmc_autoscript - understand how these work to actually boot the kernel

    Look at what the chainloaded u-boot-s905, u-boot-s905x2-s922 and u-boot-s905x-s912 are and why they are used (for extra credit, these are built from hexdump's github sources, and you can rebuild them yourself)

    Understand how the extlinux.conf file plays into the boot process

     

    It is only after understanding how each of these files plays into the boot process for amlogic TV boxes that you can hope to begin to look into changing/improving the process.

     

    The most important thing to start with is having the understanding of what hexdump mentioned above:  The boot process starts with the vendor u-boot on emmc.  The multiboot process essentially hijacks the original android u-boot process and allows other boot paths to occur that the original android box manufacture never intended.

     

  5. It would be helpful if you provided any information on what your box is, what build you are using, what steps you have taken to get to the install point you have.  If the keyboard isn't working it would imply that you don't have working usb support, which would likely indicate you are not using a compatible dtb for your system. But with absolutely no information provided that is just a guess.

  6. I was going to say much the same as hexdump.  My recommendation if you want to learn this is to start by understanding the existing infrastructure that has been put in place over the last few years to get what is currently working.  Once you build an understanding of why things are done the way they are, then you will have a good understanding on how you can help move things forward.

     

    To repeat some of what hexdump said above, you should start by understanding how the multiboot process works (and why it is necessary).  Basically build an understanding of what all the files in the /boot directory are doing and why they are needed to make a successful boot.

  7. @Sameer9793 I have a few amlogic boxes so I do have an interest, but limited technical knowhow at the moment, which is why I help out as a forum moderator.  I can answer some basic questions and perhaps provide you some guidance.  But this conversation really has nothing to do with this topic, so please open a new thread if you have some questions to ask.

  8. @Sameer9793 for context this is something balbes150 posted in a different thread this morning:

     

    "AML = shit. These chips are designed exclusively for Android. . Running Linux =  constant problem. Therefore, I refuse to work with these chips."

     

    And this is after balbes spent about 4 years of his time working with amlogic CPUs.  He has moved on to supporting other CPUs and has no interest in helping with amlogic CPUs/tv boxes.

  9. @Saru  I see you have asked in a couple of different threads the question about boards that have good support for gpu acceleration.  Unfortunately there really isn't any board that I am aware of that has very good support for gpu acceleration.  The biggest issue is the state of opensource gpu support for arm chips.  The closed source drivers exist and generally work OK, and are what android uses.  But the open source drivers are still a work in process.  The drivers are improving constantly and as they do, the integrations to other software and the specific boards take place.

  10. I hadn't heard of volumio before you mentioned it.  I see that it packages/repackages balbes150's work.  But it is ancient code - from 2018 and using kernel 3.14.  This will be incompatible with the Armbian (assuming you have 5.9 kernel installed on emmc) as well.  The scripts changed a lot over time.  You can't mix and match different boot scripts.  Unless you know otherwise, assume that you can't install/use more than one os.

    The only recommended way to switch is to revert the box to an original android firmware, and then use the os you are trying to install's installation instructions.  All of the 'install linux on amlogic tvbox' scripts are assuming you are starting from a clean android box, not something whose environment has been messed with by other installation scripts.

  11. The Armbian and CoreElec systems have different and conflicting booting scripts.  When you enable multiboot (the toothpick) you are storing the uboot environment script on emmc and this then gets used for future boots for all media (emmc, sd, usb).  So you can't just install various different OSs and expect them to work as they all depend on the uboot environment stored on emmc for the system to know how to boot them.  Basically you can't do what you are attempting to do on an amlogic based box.  In fact due to the incompatabilities between CoreElec and Armbian, it is required that if you install/attempt to install CE, that you will need to restore your box to an original android firmware in order to get it back into a state that Armbian will again work on it.

     

  12. Can you attach the file instead of cutting and pasting the contents.  I am looking at the lines in your screen capture that say:

    Ignoring unknown command:

    Ignoring unknown command:

    Ignoring unknown command:

    Ignoring unknown command:

    Ignoring unknown command: FDT

    Ignoring unknown command: APPEND

     

    It seems as if it is ignoring all the lines of your extlinux.conf file.  Is there anything you see that looks unusual?  Did you edit the file on a windows machine (perhaps windows CR/LF characters) - just making a guess.

     

  13. 4 hours ago, balbes150 said:

    (ssv6051 or ssv6252

    Adding to what balbes150 said, there is no support of these chips in mainline modern kernels.  Obviously there is support (poor if you look at the source code) in legacy kernels and therefore Android.  But the focus of Armbian is mainline and therefore from the perspective of Armbian, these chips are completely unsupported and really unsupportable.

  14. @xoodoo  Please read the following FAQ post:  https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first

     

    While the above posted thread on rk3399 support will give you information on the status of the rk3399, the latest balbes150 build with rk3399 support can be found here: https://users.armbian.com/balbes150/arm-64/

     

    I installed and ran the above build on a Magicsee M6 Max rk3399 box.  I don't know about the box you linked to above, but you can try the different u-boots and dtb files and you may find something that will work for you.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines