Jump to content

SteeMan

Moderators
  • Posts

    1365
  • Joined

  • Last visited

Posts posted by SteeMan

  1. @andybo your box does not have 8Gbyte of ddr3.  The rk 32xx cpus only support a max of 4Gbyte, so there is no manufacturer that would install more memory than could be used.  I suspect what you have thought was 8Gbyte is really 8Gbit which equals the reported 1Gbyte.

  2. 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).

  3. 3 hours ago, erduk said:

    I wanted to build an armbian image for myself but I couldn't figure it out how to do that. I looked at github in every folder of armbian source code and there is no folder containing dtd's. I couldn't find how to add new board there.

     

    If anyone can help me on that, I would highly appreciate it.

    .dts are part of the kernel (.dtb's are binary and built from the .dts source files as part of a kernel build).  The s805 dts's can be found in the linux kernel tree under arch/arm/boot/dts.  To add a dtb to the build process you would need to add a kernel patch to the armbian build that puts the .dts in the proper location.

  4. 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.

  5. 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.

  6. 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

  7. 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.  

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines