Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by SteeMan

  1. 2 hours ago, Seb_Lz said:


    As I was still searching for a solution to get eth0 working on beelink gt1, I've come across this:
    My understanding is that the dev branch includes a patch that will generate an additional .dtb file specifically for beelink gt1.


    Here is the command I used to build dev image:



    The patch you are looking at is part of base armbian, it is not included in balbes150's arm-64 build.  (The patch is from meson64-dev and you are building arm-64-dev).  So even if the build did work, you wouldn't see the result you were looking for.


    The build for arm-64-dev is currently pointing to the linux kernel next branch, which is in the midst of the open merge window ahead of 5.7, this code will be unstable for a while, that is likely the reason for the build failures you are seeing.

  2. 40 minutes ago, lu4t said:

    So, if we can reuse dtbs embedded on the native Android version, I guess we could think of mix and matching and produce a "generic" DT for Armbian. Again, I am not saying this is a simple task, I am just saying that Technically speaking if feasible and might be something that would facilitate massive adoption of Armbian.

    I am looking at this as a way to push adoption, which at the end will return this effort to the community. It's true that the ammount of work on the TO DO must be overwhealming, depending on the criteria followed to assign priorities to each pending task, this could be a nice to have feature in the future...

    Are you willing to take on this task and do this work?  I would say it is clear that the current maintainers here do not see this as a good investment of their time.  This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.


    A couple of additional thoughts on your request:

    1) From what I have observed and know of the state of android on these TV boxes is that the dtb's from android are fairly worthless in helping getting things working under mainline kernels with armbian.  Everyone assumes this is not the case, but I haven't seen anything to indicate otherwise.  The gulf between ancient android based kernels and drivers (without source code in most cases) and modern mainline kernels is vast.

    2) You are making an assumption that "pushing adoption" is a good thing.  The way things currently stand, there are not sufficient people on these forums with the desire and knowledge to provide end user support for the existing new users much less a larger quantity of new users in the future.  What is needed now is people willing to answer the basic questions that new users post here, and to work on high quality documentation and tutorials (and maintain them as things change), so that the core developers can be relieved of the burden of providing this information so that they can spend more time moving the project forward.

  3. On 3/7/2020 at 3:48 PM, rossbcan said:

    whoohoo!! solved: No Wifi Tanix TX92


    I did all the heavy lifting on this. Please incorporate changes in build (if you want), including the firmware

        patch from https://www.spinics.net/lists/linux-wireless/msg190482.html
        to patch/kernel/aml-s9xxx-current/qca9377_hw1.1.patch
        on target:
            hint: https://github.com/erstrom/linux-ath/issues/9
            cd /tmp; git clone -b bd-sdmac https://github.com/erstrom/ath10k-firmware.git
            mkdir /lib/firmware/ath10k; cp -rf ath10k-firmware/QCA9887/ /lib/firmware/ath10k
            cp /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin_WLAN.TF.1.0-00267-1 /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin
            cp /lib/firmware/ath10k/QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1 /lib/firmware/ath10k/QCA9377/hw1.0/firmware-sdio-5.bin




    qca9377_hw1.1.patch 1.71 kB · 29 downloads

    First off, I want to say thank you for contributing.  We need all the help around here that we can get.


    However, a patch like this is a example of the problems that Armbian faces (and probably to even a greater extent that the Armbian for TV boxes fork faces). 


    There are probably hundreds of different android TV boxes being manufactured.  Each with a lot of inexpensive components - wifi chips, bluetooth, ethernet, etc.  In an ideal world each manufacturer would support their products and incorporate their drivers into the mainline kernel.  But this isn't an ideal world, and many of these chips have no support by the manufacturer (probably no source code, rarely any bug fixes, security updates are unlikely).  That kind of works in the android world as the kernel version is fixed and there isn't an expectation of updates or long term support. 


    But here in the Armbian world, end users expect that there will be long term support and security and bug fix updates.  But that becomes very difficult if the upstream chip builders don't support their products.  It isn't sustainable for the limited Armbian developers to spend all their time tracking down and then maintaining hundreds of patches for all these different drivers over a period of years.  Therefore you will see in Armbian a desire to put effort into areas where the upstream code can be integrated into the mainline kernel (hopefully by the original manufacturer), so that patches only need to be maintained for a couple of kernel release cycles as the code get integrated into mainline. 


    So while I know nothing about the wifi chip that your supplied patch supports, it there isn't an effort by someone upstream to be integrating that into the mainline kernel, it probably doesn't make sense for it to be incorporated here.  The long term maintenance costs aren't worth the effort. While there certainly are exceptions, that is how I see the reality of being of the current Armbian environment.  The project is not able to support the wide variety of components that exist in all the different SBC's and TV boxes being produced today or over the last 5 years, so the effort goes to where there is the most support from upstream suppliers.

  4. 42 minutes ago, rossbcan said:

    It was a simple question: how to use linux-headers from released build system, hoping someone has run into this already.


    @SteeManappears to suggest if I work with dev as opposed to current, headers may be OK. Maybe so, but hard to get repeatable builds at bleeding edge, so, I will stick with current until dev becomes current+

    Your reply indicates I think a misunderstanding of the status of the Armbian TV Box fork builds (I think we need a better name for these builds).  You mention the "released build system" and that "current" is more stable than "dev".  Those are both incorrect understandings of the current state of the TV box builds. 


    First off there isn't a "build system" for the builds off of this fork of Armbian.  The builds are simply what balbes150 decides to release to the community for testing.  And the "current" vs "dev" is simply a difference in which kernel tree is being used in the build.  "current" being a significantly patched 5.6ish kernel and "dev" being an unpatched mainline "next" or "rc" tree.


    These Armbian for TV box fork builds are essentially snapshots of balbes150's development work, some more stable than others less so.  There isn't any formal release management process around them, nor are they reproducible from a specific git tag (if you look at balbes150's Build_armbian github tree there are no tags or branches).  This work is purely the stream of effort that one developer can put into this fork of Armbian.  I don't want to come across as complaining about the current status nor downplay balbes150's efforts.  It is obvious to me that for the continued progress of these efforts, we need to figure out a way for balbes150 to focus on his strengths (moving the development efforts forward), and the rest of us need to step up and do more of the end user support on these forums and work to bring some structured release management to this code base.  The core Armbian team has been focusing on it's release management process recently and I think the results of that effort are great.  Something similar needs to happen here with the TV builds as well, but balbes150 can't do it all by himself.


    Since I have more time recently (being stuck at home), I am trying to answer more questions on these forums.  But it has taken me almost a year of observing to feel confident in being able to contribute knowledgeable information.  I am also starting to dig into the build system to better understand it with the intention to submit patches that will improve the release management side of things for the TV box builds.   I can't do what balbes150 does for this project, but there are things I can help with, and hopefully I will be able to.

  5. 23 minutes ago, rossbcan said:

    Hi Folks;


    (Tanix TX92) uname -a: Linux aml-s9xxx 5.5.1-aml-s9xxx #trunk SMP PREEMPT Thu Apr 9 17:54:57 EDT 2020 aarch64 aarch64 aarch64 GNU/Linux


    I need kernel headers to build some out of tree kernel modules such as openvfd but have been stuck for several days.


    Research / experience has shown that:

    - lot of obsolete information - old kernels

    - armbian-config fails to install headers

    - No correct linux-headers version available for download

    - ./compile.sh INSTALL_HEADERS=yes does install headers, but issues (forum search) due to WIREGUARD

    - ./compile.sh INSTALL_HEADERS=yes WIREGUARD=no is required for proper headers (still true?)



    - "make ARCH=arm64 scripts" fails due to the tool binaries being x86_64

    - "make ARCH=arm64 clean" (attempt to rebuild tool binaries) fails "scripts/Makefile.clean:67: recipe for target 'drivers/gpu/drm/arm' failed"


    So, how to I get a usable set of kernel-headers?





    The build you have installed is built from balbes150's fork.  You don't mention which git tree you are working with, but you should be working with https://github.com/150balbes/Build-Armbian

    I believe balbes150 just removed the s905xxx targets and consolidated into the generic arm-64 target, so if you use the current head of the git master branch you will be working with newer kernels.  I pulled this code yesterday and built Armbian_20.05.1_Arm-64_bionic_current_5.6.2_desktop.img and in output/debs is the headers package linux-headers-current-arm-64_20.05.1_arm64.deb

    It is unlikely that you will be able to rebuild the header package that corresponds to your currently installed build, but you can certainly build a current version with headers for you to work with.

  6. 15 minutes ago, Nikeb said:

    I m using Armbian_5.77_Aml-s812_Ubuntu_bionic_default_3.10.108_desktop_20190326.img

    The build you are using would be a build from balbes150's fork.  As you can see from the build date, that build is over a year old and on a kernel version (3.10) that is almost 7 years old.  If you value security you really shouldn't be using such an old build.  balbes150's work is now focused on current mainline kernels (5.4 or higher).  Since the build you are using predates my involvement in these forums, I have no idea if installation to internal storage is possible with what you are using.

  7. 7 hours ago, Nikeb said:

    I'm trying to install it on the ROM of the Minix (wich i guess is NAND) but i can't find the nand-sata-install script (command not found) or in the armbian-config (there is no such menù "Install")

    Is something that i could do? use the armbian OS from the minix drive without SD Card?

    Assuming you are using one of balbes150's builds, then follow the information in this post:


  8. 49 minutes ago, amirdelta said:

    so if i have had access to  source of kernel header, i could have right a visual instruction to.

    You do have access to the source for these builds:  https://github.com/150balbes/Build-Armbian and https://github.com/150balbes/Amlogic_s905-kernel (actually these git trees are usually a few days behind the most recent balbes150's builds as he waits for code changes to stabilize before pushing them back to these github trees)

    I would recommend you start by pulling the Build-Armbian environment, and building the equivalent of what you currently have installed.  You will see that the build system creates the kernel header package as part of the build process.  Then you can experiment with improvements and contribute back to the overall community.

  9. On 4/3/2020 at 8:30 AM, balbes150 said:

    Version 20200403.

    Fixed automatic fetching of the kernel from the network repository.

    I did some testing of this new feature and it seems to work well.  I installed the above version.  Then I pulled your source from github, bumped the version number to 20.05.2 built the .deb files and then did a local update to the new deb files and the update was successful.  Thank you for your continued work on this project.

  10. I am starting a new thread as this discussion doesn't belong in the "Single Armbian image for RK + AML + AW" thread.


    The end user need is that users (I think this is especially true of TV box users) think of Armbian for TV boxes like a standard linux distribution.  What this means is that they expect to receive security updates and critical bug fixes.  They are after all trying to run home servers and desktops on this platform.  And for the most part they get these fixes from the upstream distributions (ubuntu or debian).  However they don't get fixes for the linux kernel.  The question "how do I get kernel updates?" gets asked quite frequently in the TV box sub-forum (and if users aren't asking that question they probably assume they are getting updates through apt and don't realize they are not, or don't care at all about security).


    @balbes150 has been working on building linux-image .deb files for the TV box builds, and I think with today's patches he has that working (i've looked at the code, but haven't tested that yet).  He has also been experimenting with deploying these kernel images via apt.armbian.com.  As was just discussed in IRC @igor correctly points out that the Armbian TV box work is a fork of Armbian and not supported.  But if we are using armbian infrastructure to deploy TV box kernel builds that line is certainly blurred.


    There are a whole lot of release management questions and support issues that need to be worked out before this is all going to work smoothly.   And I think it is better for this to be planned and discussed so that everyone agrees to the strategy and supports it.


    At the end of the day, my personal desire is to be able to install an "Armbian TV box release" of for example Ubuntu 18.04 on an LTS kernel (i.e. 5.4) and to have apt install all security and critical bug fixes for both the kernel and other packages for a couple of years without giving the box much thought (like I would with any other server linux distribution) - the fact that I want to do this (and hopefully can someday) on a sub $50 box that originally ran android is the incredible value that this project brings to the world.


    So how should we deploy kernel images for Armbian TV Box builds?



  11. 33 minutes ago, balbes150 said:

    P.S. Do not rush, a new version 5.6-rc7 is coming soon.  I plan to send it to the Armbian network repo (I have already uploaded some deb files to my site along with the new version of images).  :)

    Shouldn't the kernel version be part of the package name for proper versioning of new kernel builds?  I see that you have moved the 20200404 build to armbian version number 20.05.1 (I am assuming this was to allow for proper versioning of the .deb files).  Also, are you planning on releasing regular arm-64-current, arm-64-dev, aml-s9xxx-current, aml-s9xxx-dev, rk and alwinner kernels?  (I am assuming that you are not :-) as there are only 24 hours in a day).  Do you need any help with this?  The reason I am asking is that I am looking for stable kernel upgrades for the servers I have running on my tv boxes.  I am currently building them weekly as new mainline kernels are released.  I have just started looking into your deb packaging patches and would like to help if there is something that I can contribute.

  12. 4 hours ago, hanguofu said:

    Thanks for sharing your knowledge !


    I am going to check out the branch linux-5.6.y  from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git  . But I had a problem to find out the   kernel source version for the 'stable', 'current' and 'dev' builds : when I checked  config/sources/families/meson-gxl.conf , I didnot find out the version name .  Which patch version ( meson64-current , meson64-dev , meson64-legacy ) should I apply to that branch please ?

    In the TV box builds, balbes150 is focusing most on the aml-s9xxx and arm-64 areas.  So if you look at config/sources/families/aml-s9xxx.conf or arm-64.conf you will see something like this:

    case $BRANCH in

    From here you can see that 'current' is on the 5.6 branch. So if you look in patch/kernel/aml-s9xxxx-current you will see the packages-current.patch which is what you want.  (I just realized in my instructions I called this patch by the wrong name, in my instructions I say build-?????.patch, but the name really is packages-?????.patch).  You will notice that balbes150 maintains his own patched kernels that he builds from (KERNELSOURCE).  I have been generally using unpatched kernels from kernel.org so I know exactly what I am building.  But once you understand what is going on, you can experiment with different kernel sources and find what works best for you.  Because in this case balbes150 kernel tree is already patched, there isn't in this patch directory the other required patch (text-offset.patch).  You can find that patch in the 'dev' build (patch/kernel/aml-s9xxx-dev/text-offset.patch) as that build is against a non-patched kernel tree.


    You mentioned looking at meson-gxl, which I assume means you are working with an aml s905 based tv box.  I use and build kernels for TX3mini boxes that have the s905w cpu (meson-gxl-s905w-tx3-mini.dtb) and yesterday I built and installed both the 5.4.30 and 5.6.2 releases that came out yesterday on my TX3minis.


    My recommendation is to start simple, learn, and then experiment with more things.  I find that the 5.4 and higher kernels have good support for the amlogic chips (at least up through the s905x3) and as long as I am using these boxes for servers they work fine for my needs.  (i.e. I don't care about wifi, bluetooth, etc).  But if you need more than the base kernel supports, you can start looking at the kernel patches that are around and finding things that you want to experiment with and add them into your build environment.  I find this is a good way to explore the evolving support of these arm based TV boxes.

  13. 9 hours ago, vipk31 said:

    I install armabian success on SD card

    and make guid https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb


    but error command not found

    I used armbian :  Armbian_20.02.0-rc1.037_Aml-s9xxx_bionic_current_5.5.0-rc6_20200205.img.xz

    Can current armbian be installed on eMMC?

    please help me .

    The standard armbian documentation only applies to the standard armbian builds.  The builds by @balbes150 are a fork of the standard armbian code for Android TV boxes (instead of standard SBC boards) and therefore you can't use the standard documentation as there are a number of differences.  To install into emmc look in your /root directory and you will see a set of install scripts.  Choose the one appropriate for your CPU and run it for installation into emmc.  The current active thread of discussion for the @balbes150 builds is: 

    Please carefully read the first posting in this thread as it goes over many of the specifics that are unique or different for these android tv box builds.

  14. 38 minutes ago, psxsnake said:

    Yes this i know via apt

    but If I wanna change from buster to bionic or focal?

    You would repeat the process you just completed.  Create a new sdcard with the desired distribution, then copy that to internal emmc with the provided scripts in the /root directory.  If you boot the box with the sd card inserted, the box will boot from the sd card, thus allowing you to overwrite the contents of the internal emmc.

  15. 19 minutes ago, psxsnake said:

    If I wanna change build, i cannot do update from sd as before so how i proceed?

    I'm not sure what you mean by change build.  So I will try to answer the best I can.  Once you have installed a build onto internal storage, you would use the distribution tools to get updates for all of the software packages (i.e. apt update/upgrade).  This will get you patches for everything except the linux kernel.  You are currently stuck at the linux kernel you installed as there aren't currently kernel updates automatically provided via apt for the Armbian TV builds  So to get kernel updates you would either need to completely reinstall everything from a new sd card build, or build your own kernel from source and install it manually.

  16. 3 minutes ago, psxsnake said:

    what you mean? becouse the "appropriate script" should be armbian-config, in according with document page


    but this 20.05 version doesnt have the part with INSTALL ON NAND

    The standard armbian documentation only applies to the standard armbian builds.  The builds by balbes150 in this thread are a fork of the standard armbian code and therefore you can't use the standard documentation.  Look in your /root directory as I indicated and you will see the install script you need to run for installation into emmc.

  17. 5 hours ago, gabe5000 said:

    Now I'd like to install the system on the eMMC. I started to follow  the Armbian documentation, but the 'nand-sata-install' command is not recognized.

    Could you please help me what to do?

    For the Armbian TV box builds, there is a script in the /root folder that you need to run to install into emmc.  There will likely be multiple scripts in this directory, you run the one named appropriately for your device.

  18. As I have been watching the development of Armbian for TV boxes, there is one area that my needs haven't been addressed yet.  And since this is open source that means I needed to read a lot of posts and get into the code to understand how things are working.  I have been doing that over the last six months or so and wanted to report back on what I am now doing to solve my issue as it may help others.


    I have a number of TV boxes running as headless servers for a variety of projects.  Once I install Armbian on them I then get OS updates through ubuntu (I am using Ubuntu Bionic on my boxes).  That gives me bug fixes and patches for the software running on these boxes via apt update/upgrade.  However the linux kernel generally stays unpatched at the point in time that I installed one of balbes150's TV box builds.  What I wanted was to be able to build and update kernels so that I can apply new kernel versions to my servers.


    I am now able to do that successfully across a number of TV boxes ( TX3mini, TX3 X3, H96 Max X2) (Note I only have amlogic based boxes that I test with).  I am building kernels from kernel.org sources, building .deb files and then installing those files across my servers as new kernel versions are released.  My goal was to simply stick with the 5.4 kernel as it is a long term support kernel, but I find that I have moved to 5.6 as I wanted native wireguard support.  Another goal I have is to do all this with as few patches as possible (i.e. running stock base unmodified linux).  And a final goal was to build natively on my arm based boxes.


    Below are my notes that explain what I have done and hopefully provides others with some of the knowledge I have built up over time to be able to get what I needed working.


    I hope this is helpful to others who want to get their hands into armbian a little deeper than just installing and running it.




  19. 17 hours ago, flagadajones said:


    i've made many other tests.

    I've installed Coreelec on my eachlink X3mini  ( S905X3)  with the dtb sm1_s905x3_2g. It boot and all is ok.


    how Is  possible to adapt this dtb for armbian ?



    The short answer to your question, is you can't, or at least you can't if you are not the device manufacturer or possess skills that very few people have.


    The longer answer is that coreelec and Armbian are very different projects with very different goals.  Coreelec's goal is to provide a basic linux environment to run kodi using the vendor supplied linux kernels.  I believe that for your device that would be a 4.9 kernel.  Armbian on the other hand provides a full linux distribution on mainline linux kernels (currently 5.6.x). 


    So instead of using a heavily modified custom vendor supplied kernel that never gets any security updates or bugfixes (coreelec case), with Armbian you get a fully community supported kernel with the most current security and bug fixes available.  The problem is that if the device manufacturer and cpu manufacturer don't care about getting support for their devices and chips into the mainline kernel, then Armbian can't support them very well.  And if the source code isn't available to others to port to the mainline kernel it is practically impossible to ever get good support for these devices in the mainline kernel and thus armbian.

  20. 5 hours ago, flagadajones said:



    i try  to install Armbian  on  a eachlink X3mini and i have always the same error with different dtd file.

    i try this for get dtb file


    It looks like you are trying to use a dtb from your android installation.  dtb's are very much tied to specific kernel versions and an android dtb based on an older android kernel will not work with a current armbian built kernel.  You need to be using one of the dtb's that are part of the armbian build you are using (or are building a dtb that will work with the armbian kernel you are using).

  21. 50 minutes ago, zanfi said:

    Right, but... I should see some boot on screen I believe...or am I wrong?

    I do not see anything at all, that's why I believe I'm doing something wrong.


    It depends what you mean by screen.  It you mean a terminal program listening on the uart port, yes you should see something, if you are expecting to see something via the HDMI port then no.  HDMI is initialized late in the process and depends on most things working/configured properly to see anything.

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines