SteeMan

Per the topic of this thread the 'arm-64' images support all three chipsets (rockchip, allwinner, amlogic). Just follow the instructions in the first post of this thread.

I will retest. When I tested last week, I didn't have any audio on my boxes. I had assumed this was because you were still working on the changes you were making. But now that you are done with these changes and expect it to work, I will retest and let you know the results.

Without any information about what box you have or what version you are working with, there isn't enough information to answer your question. I will however add my general observation that the answer is "maybe but probably not". For example I don't have any working audio on any of the boxes I am running (not even under HDMI, let alone optical). I consider working audio in these builds on most boxes to be something you are lucky to have working, but don't expect it to work. (Much like wifi and bluetooth generally don't work on many boxes, and people shouldn't expect them to work).

It should be possible to build a local kernel. I have been doing it for a while now and have similar boxes (s905w, s905x2 and s905x3). Here is what I have been doing. Now let me see if I can remember all of the setup steps I did to get a working environment to build and deploy into. 1) My builds are against either 5.4 or 5.6 kernel.org sources (i.e. git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git) 2) I used the kernel config files from a corresponding balbes150 build against the same kernels (so the correct options are being compiled in) 3) I applied the text_offset.patch mentioned above in this thread so that I didn't need to modify the boot command in the autoscript files 4) I modified my uEnv.txt file for the location of the dtb (which I have been putting in /boot manually, instead of a /dtb directory) 5) I think that is all, but I am probably missing something important Given your goal above, I would start simple (just getting a user built kernel running) then start adding in the other features you are looking for (zfs in your case). # Sync git with kernel head git pull # make the necessary components make LOCALVERSION= -j4 Image modules dtbs sudo make modules_install sudo make dtbs_install # convert image for install sudo cp /boot/uImage /boot/uImage.bak sudo mkimage -A arm64 -O linux -C none -T kernel -a 0x01080000 -e 0x01080000 -d arch/arm64/boot/Image /boot/uImage # copy over the new dtb file(s) (because the default dtb directory is versioned, this copy prevents the need to edit the uEnv.txt file every time the version number changes) sudo cp /boot/dtbs/<linux_kernel_version>/amlogic/<whatever-dtb-you-need.dtb> /boot # prepare the initrd sudo cp /boot/uInitrd /boot/uInitrd.bak sudo update-initramfs -c -k <linux_kernel_version> # reboot sudo shutdown -r now #if everything worked you are now running the new kernel # cleanup as needed sudo rm -r /boot/dtbs/<old_kernal_versions> sudo rm -r /boot/initrd.img-<old_kernel_versions> sudo rm -r /lib/modules/<old_kernel_versions>

You probably need to be more specific about your requirements. What features do you need working and what are you planning on using it for. I have 4 TX3 Mini 2gb/16gb boxes (the version without the display). I use two of them for servers, a third to test with and the fourth I use the original android firmware to run a digital display. These can be found for $25 or less (for example https://www.aliexpress.com/item/4000537589239.html). I use the meson-gxl-s905w-tx3-mini.dtb file. Ethernet and hdmi work but no wifi or bluetooth. This box at this price point is on the low end, so don't expect to watch 1080p video, but for light web browsing it works fine. Now the problem I have. On two of the boxes I have installed to internal emmc and everything works fine. However the last two boxes I bought, don't have emmc. Instead they have internal cheap nand which can't be accessed. There is nothing about these two nand boxes that indicate they aren't what they are advertised to be, until you open them up and look at the chips that exist on the board. When you are looking for cheap, there are a lot of vendors that sell knockoffs that look like the real thing but come with substandard components in order to cut costs. Buyer beware.

I think this is the core of the misunderstanding of the complexity of the issue. Both of your points 1 and 2 are based on a false understanding of the environment. The underlying problem with your understanding of the problem is your statement "this dts is the hw manufacturer description of their own hw". It is much more complex than that in reality. The dts is essentially descriptive code that ties the hw, driver, and kernel together. Any of those three things changing will have an impact on the contents of the dts. So even though the hardware is the same, the driver software and kernels are not. So the dts needs to be modified to correspond to the expectations of the target driver software and target kernel. Unfortunately often the original driver software source code isn't available and android kernels are significantly different than mainline kernels. So usually there isn't any use in having the original android dts in trying to support a particular box under armbian with mainline kernels.

What you describe can theoretically be accomplished today through the use of device tree include files (.dtsi). And if you look at the source code, you will see that this mechanism is already used extensively to overlay board specific items on top of base CPU specifications. Adding an additional layer on top doesn't provide additional functionality that couldn't be accomplished today. Howerver, the scope of the problem is much bigger in the armbian world than in the Android and Raspbian world. In both Android and Raspbian the base hardware is more constrained (i.e. the models of Raspberry Pi are a relatively small number with a small set of well known cpus, etc). In the TV box world of armbian, you have three different primary CPU manufacturers (Amlogic, Rockchip, Allwinner) each with a wide variety of different cpu architectures. Then you have many, many manufacturers that are putting together boards with all manner of third party chips for memory, nand, wifi, ethernet, bluetooth (and for most of them there is no source code available). And since the goal of these manufacturers is to produce the cheapest tv box possible, they are likely using components that are inexpensive and thus not well supported. Combine those hundreds of different devices with the fact that there is no upstream support from the board manufacturers and component makers to support their products (not even providing source code for others to do it) and you have a massive undertaking. Then consider that there are only a handful of developers within armbian capable of working at this level of the code and you have a problem that isn't solvable today.

If you want help in these forums, please do your research first (by looking at information already in the forums), follow existing instructions, and please be more detailed in your problem descriptions. Based on what you have provided in your post, I can state the following: 1) There is no current support for the Allwinner H616 (that is a new chip, and support for it hasn't worked its way in yet). There are other discussions about this in other forum threads. 2) The link you reference is for an entirely different tv box with a different chip. The link you posted is for a "T95 Max" which is based on the Allwinner H6, which is supported. There are many variants of these tv boxes with similar names and each is likely to be very different internally. Also two boxes with the same name can also vary in terms of their CPU and other components. 3) You mention that you found a dtb file that you were trying. (So much more information is needed here: What dtb?, where did you find it?, why do you think this will work?, what instructions are you following that suggests this will work?, what kernel was that dtb built for?, what kernal are you trying to user it with?) In general you simply can't do what I think you are trying to do. If the dtb file isn't part of the distribution you are installing, there is about a 0% chance it will work. There are no instruction that I am aware of in these forums that suggest that you should try what you are trying and expect it will work. Stick to things that are documented as working (like the first post of this thread) if you are asking for help. Or if you really do intend to experiment, make it clear in your posting that you are not following the documentation and trying something different, so that we don't waste valuable time trying to help you.

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.

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.

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.

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.

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.

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.

Is your system clock correct?

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

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.

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.

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?

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.

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 legacy) KERNELDIR='linux-aml-legacy' KERNELSOURCE='https://github.com/150balbes/Amlogic_s905-kernel' KERNELBRANCH='branch:5.3' ;; current) KERNELDIR='linux-aml-current' KERNELSOURCE='https://github.com/150balbes/Amlogic_s905-kernel' KERNELBRANCH='branch:5.6' ;; dev) KERNELDIR='linux-aml-dev' KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git' KERNELBRANCH='branch:master' ;; esac 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.

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.

You really should move to a recent build from the current builds for Armbian TV boxes from this thread: https://forum.armbian.com/topic/12162-single-armbian-image-for-rk-aml-aw/

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.