Jump to content

Trying to learn more about u-boot for amlogic devices.


Sameer9793

Recommended Posts

@Sameer9793- i collected some notes around mainline u-boot for amlogic in the readme.gxb (gxbb), readme.gxl (gxl) and readme.gxy (g12a, g12b, sm-1) in this repo: https://github.com/hexdump0815/u-boot-misc - but i would recommend you to play around with that stuff only if you really know what you are doing as you can very easily brick your box this way and then nobody can help you ...

 

good luck and best wishes - hexdump

Link to comment
Share on other sites

@Sameer9793 - amlogic socs by default always boot from emmc if emmc is there (which is always the case for tv boxes) - best for you is to look at the multiboot script from the old images of balbes150 - this one uses the legacy u-boot of the box to boot an own kernel or to chainload a mainline u-boot to boot it - those options should be quite safe as everything else which does not write anything to emmc

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

1 hour ago, SteeMan said:

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.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt

 

1 hour ago, SteeMan said:

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

https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.distro

Link to comment
Share on other sites

@SteeMan and @usual user thanks for the reply. i know what most of the stuff do in the boot directotry, i know that the extlinux.conf file specifies the kernel image, the ramdisk image, dtb file, the bootagrs, which is the rootfs parition and where to mount it (obviously on /). 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). thats basically it, i even got official archlinux working without any errors by using the u-boot.ext, aml_autoscript, boot.ini, emmc_autoscript, s905_autoscript, extlinux/extlinux.conf, "Image" (kernel file for archlinux comes with the rootfs), "initramfs-linux.img" (ramdis image for archlinux this also comes with the rootfs.), after that specify the kernel image and ramdisk images in extlinux.conf file. after that i just paste those files in the fat32 boot partition and extract the arch rootfs in the ext4 partition and just install a display manager and a desktop enviorment and install the "xf86-video-fbturbo-git" package from pacman that package is the key because those are the mali video drivers without them xorg will show no screens found.

 

but i would love to know how to build the u-boot-s905, u-boot-s905x2-s922 and u-boot-s905x-s912 files by myself.also is there any way to build the s905_autoscript and emmc_autosciprt and boot.ini by myself?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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?

 

My android tv box is "Tanix tx3 max" with amlogic s905w SoC

Link to comment
Share on other sites

8 hours ago, SteeMan said:

The balbes150 builds do not use this file.  While it may exist,

i opened that file with a text editor and saw there was some code like this at the end of that file 

if fatload ${devtype} ${devnum} 0x1000000 u-boot.ext; then go 0x1000000; fi;

 

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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

Link to comment
Share on other sites

17 hours ago, SteeMan said:

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.  

Does booting from manjaro, armbian, archlinux and kali linux on my android tv box without reflashing the rom do anything or make any difference to the enviroment variables?(all of those distros use the u-boot.ext, extlinux.conf method)

Link to comment
Share on other sites

I've never tried the other distros so I can't answer your question.  But given the information I have provided above you should be able to answer your own question by looking at the scripts in the various distros you have and comparing them to the ones in the armbian build.  I would suggest you compare the aml_autoscripts first (as the aml_autoscript is basically only setting u-boot environment variables).

Link to comment
Share on other sites

@SteeMan thanks for all the information you have gave me about u-boot on amlogic devices. I have two last questions.

 

Question 1. are rockchip tv boxes any different from amlogic tv boxes? Is here any difference between running linux on amlogic and running linux on rockchip? is it any easier?

 

Question 2. Is there any other place where i can talk to you like discord or something else where i can get answers reletavily quickly rather than armbian forum where it takes 1 day sometimes 2 or 3 hours since both of us have different timezones.

Link to comment
Share on other sites

@Sameer9793  The TV Box environment for amlogic and rockchip is very different.  In these forums there are two threads that cover a lot of the rockchip varients (https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes and https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards)

@jock and @fabiobassa are the two experts in that area in the forum.

Link to comment
Share on other sites

@SteeManby any chance is there any way to flash a image to my android tv box emmc via usb burning tool and use it as a sbc and flash images to an sdcard and boot of it without needing to hack the vendors u boot and without needing to use u-boot.ext, aml_autoscript, s905_autoscript and emmc_script and only use the extlinux and kernel images and ramdisk images, just not have to care about things breaking and flash the newest uboot to andorid tv box emmc so it can boot linux distros from sdcard without needing to use u-boot.ext file (this was just a thought that came in my mind).

Link to comment
Share on other sites

I'm also trying to learn more about the boot process, I currently can boot from a USB SSD unless anything else is plugged in to any USB port except a powered hub, if anything is plugged in that powered hub, it will not boot also. If I put the fatload mmc 0 entry last in the s805_autoscript.cmd file will that fix it? It seems to be an addressing issue, rather than a power issue.

I am using stretch 310.108 with no DTB selected, and everything works except the Mali 450

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines