SteeMan
-
Posts
1654 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SteeMan
-
-
Then the short answer is there isn't source for these no longer supported (technically never supported as TV Boxes have never been officially supported) builds.
However, you seem to have sufficient technical skills and therefore I will point you down the path of building your own kernel (and thus you will have everything you need). Review the following thread: https://forum.armbian.com/topic/9625-compiling-and-booting-mainline-linux-for-your-s9xxx-tv-box
That is where I began my journey with armbian on amlogic TV Boxes. I think everything in that thread, (mostly thinking about my post with instructions) is still valid, although I have moved on to doing things differently now days. But I am running latest verisions of 5.4LTS, 5.10LTS and even 5.15.rc on various TV Boxes as I write this. So if you have the proper skills, you are not stuck with the kernel you currently have running.
-
First I suggest you read the following FAQ post:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
-
Moved thread to the proper TV Box area
-
On 9/29/2021 at 1:31 AM, Sameer9793 said:
if fatload ${devtype} ${devnum} 0x1000000 u-boot.ext; then go 0x1000000; fi;Yes that has confused me as well. I don't know why balbes modified this file in his builds, but if you follow the u-boot process (starting with aml_autoscript) and then s905_autoscript/emmc_autoscript, you will see that it is these later two scripts that are responsible for loading u-boot.ext, not boot.ini
-
On 9/29/2021 at 1:25 AM, Sameer9793 said:
totally offtopic but @SteeMan does booting from the old dtb.img boot method disables the u-boot.ext, extlinux.conf method? one day i tried emuelec on my android tv box it wrorked but after a bit of tinkering around with it i got bored and tried to boot to my manjaro arm sdcard but it wouldent boot, it just boots to the android recovery, so i had to reflash the android rom on my android tv box and after reflashing it was booting fine(i had to reinstall manjaro cause all the files on it was owened by 0123 and all the permisssions were messed up). is that supposed to happen?
Not offtopic at all. This is actually a critical thing to understanding how the boot process works on these amlogic boxes. The link I posted in my last comment gets into this very issue. The short version is that the 'multiboot' hack sets u-boot environment variables that are persisted on emmc storage. Overtime the 'multiboot' hack has evolved and different distributions do it differently. So one multiboot can set the u-boot environment variables in ways that are incompatible with other distros. That is why the installation instructions warn against trying different distributions without reverting back to a clean android firmware in between.
-
@Sameer9793 Please look at the following thread that I have ongoing with someone else. It covers some of the same ground as we are talking about here and I don't want to have to repeat myself https://forum.armbian.com/topic/19022-s905x-p212-balbes150-2010-ignores-extlinuxconf
-
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.
-
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.
-
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.
-
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.
-
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.
-
Please read the following FAQ item from the TV Box forum:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
-
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.
-
@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.
-
@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.
-
@Sameer9793 balbes150 no longer is working on the amlogic TV boxes. He is not going to respond to your repeated requests. Remember that this project is volunteer based and each volunteer decides what they want to work on.
-
You need to provide information on what you are trying to do, what steps you have done, and what issues you are having.
Have you read the FAQ items:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus
-
@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.
-
There is no upgrade path. Please read the FAQ items:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus
Your only realistic option is to reinstall a later version (5.9) but those builds are now a year old and unsupported as well.
-
@dorin I was going to suggest that you look at which u-boot you were using, but you figured it out before I had time to reply.
-
@xoodoo You have access to the source code so you are free to work on support for your box. I don't think you understand how much time and effort what you are requesting takes, however. Having never heard of your box model, and I suspect no one around these forums has this box, you are likely on your own.
-
As was stated in the FAQ, don't expect to get working wifi on these TV boxes. I have over 10 different boxes and wifi doesn't work on any of them. If you need/want wifi, the best way is through a usb wifi adapter.
-
Are you sure your dtb file maps to the correct wifi? The purpose of the dtb is to map the hardware to the kernel. If you don't have the correct dtb you will never get the correct driver to load.
-
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.
X96 mini not boot armbian corectly
in Amlogic CPU Boxes
Posted
Are you sure your box has 2GB of RAM? It is common for these cheap TV Boxes to be mislabeled and there are even cases where the Android install is modified to lie about how much ram exists. The only sure way to know is to open the box and look at what ram chips are actually installed on the board.
If you do have 2GB of ram with only 1GB being used, that would be an issue with the dtb file you are using, as the dtb maps the hardware to the linux kernel.