SteeMan

blind@TX3X3:~$ free total used free shared buff/cache available Mem: 3684488 859436 2103944 24008 721108 2643560 Swap: 1842240 0 1842240 blind@TX3X3:~$ This is on a TX3 with s905x3 using meson-sm1-sei610.dtb And on a H96 Max with s905x2 using meson-g12a-u200.dtb: blind@H96MaxX2:~$ free total used free shared buff/cache available Mem: 3365644 216796 1203640 21244 1945208 2966404 Swap: 1682820 0 1682820 blind@H96MaxX2:~$

I don't expect that you will be able to get the remote control to work. I generally don't expect that you can get wifi or bluetooth working. The nature of these TV Boxes is such that if you get successful video and audio via hdmi and wired ethernet working you are doing good. Anything beyond that is more likely than not to not work. This is because there are probably a hundred different hardware configurations out there and none of them are supported by their manufacturers to enable the community to implement anything but the most generic features.

This is an open source project. So therefore if you want a particular feature you are welcome to implement it yourself, or you could offer to pay someone else to implement it for you. To request or expect others who are volunteering their time to an open source project to implement something specific for your needs is not in the spirit of open source.

It is theoretically possible. But since each box is different you would need to get information from the device manufacturer (and likely source code for the specific hardware in their box) to be able to write a custom utility to do this. I am not aware of anyone who had been able to do this successfully as generally the device manufacturers do not offer any type of support like this for their hardware. That is a primary difference between a single-board computer like an Orange Pi and a generic TV box. The SBCs are built for developers and generally include documentation and source code for the boards, but the TV boxes are generally completely unsupported (which is also why they often are cheaper for similar specs due to not needing to provide support).

The dtb mechanism has support for a feature called "overlays" which is in theory designed for the use cases you are thinking about. But the basic problem is getting all of the dtb specifics in place for a particular box and then figuring out how to make the selection process easier. The hard part is the first part of that problem not the second. The first step is to get working dtbs for a set of different device configurations and then finding the best method to select them. While there are hundreds of different android tv boxes out there (even the same box based on outside markings can have many different clones/versions with different internal hardware) each requiring a different dtb to correctly map the specific hardware for each box, and only a handful of dtbs in the distribution, you have the situation we find ourselves in.

It is theoretically possible. But I haven't seen this successfully done. To undertake a task like this you need access to source code and support from the underlying device manufacturers, which generally doesn't exist. (This is part of the reason that balbes150 doesn't support the s905x3 cpus as Amlogic does not provide support for their products under mainline kernels).

Current builds for armbian on android tv boxes can be found along with current instructions for installing them in the first post of the following forum thread:

You will need to be more specific in your question. What ubuntu distribution are you referring to? When you say ubuntu do you mean armbian? When you say "this" what exactly are you referring to?

The AML specific builds are no longer maintained (thus why you are seeing no focal build and nothing current in the location you are looking). The current builds are now "universal" builds that support Amlogic, Rockchip and Allwinner CPUs for android TV boxes. Look at the first post in this thread: The instructions for installing are basically the same as the build you are using, but with additional options for the various CPU families. These builds are being regularly updated and is where you should be looking for installation images.

From the information you provided you are running Ubuntu 18.04 (bionic) which has python 3.6. I believe that Ubuntu 20.04 (focal) has python 3.8. So the easiest thing to do would likely be to use the armbian focal build instead of the bionic build.

You didn't follow the instructions correctly. The instructions say to "copy" the u-boot.sd file, not rename. The install to emmc uses the u-boot.sd file so if it doesn't exist because you renamed it you would see the problems you are having. Fix this situation on your sd card and redo the install to emmc.

I don't see anything in the links you have provided that this would be a solution to your problem. Are you sure that you have the that chip on your board? (i.e. have you opened the case and inspected?). In order to get things working, you need to have your dtb, driver and hardware all in sync. The dtb is the mapping between the hardware and the kernel, I would expect that this is the real source of your problems that your dtb is referencing different hardware than what you have installed on your board. The problem with armbian for android tv boxes is that while there are only a few different reference dtbs available, but there are hundreds of different boards with different components from all the manufacturers. So most of the boards will not work in some way because of the mismatch between their hardware and the dtbs that are available (sometimes you get lucky and everything you need works, but rarely does everything work). As I have said in other threads, no one should approach armbian for these tv boxes expecting that everything will work (especially wifi and bluetooth - none of my boxes have working wifi or bluetooth) because that is not a reasonable expectation, unless the board manufacturer is supporting their boards by getting code into the mainline kernel. Having said all of that, it wouldn't hurt to try what you reference in the links above, and I suspect it is likely that the 5.6.1 based code would still work on a 5.7 kernel. You should also consider the long term support issues even if you do finally get something working. You will likely find yourself in the position that at some future point in time when a new kernel update with important security fixes gets pushed out that it is no longer compatible with your custom built driver and then you will need to choose between security of your system or breaking your wifi support. If you need wifi, I would recommend getting a cheap usb wifi adapter that has mainline kernel support as over the long run that will be best. However if your goal in all of this is to get your solution into future armbian builds (which really means getting it into mainline kernel) then keep hacking away. But I would suspect that because you have already found a git repository that contains driver code that isn't in the mainline kernel (I am assuming this, but haven't verified), that that path has already been tried by others and rejected (lack of support of the code, poor code quality, or any number of other reasons).

Thanks. Since your post said, "no patch" I was hoping that this patch was no longer needed. I applied what I think the changes should be and am testing my own builds now on 5.8-rc1. When you push your changes to Build-Armbian I will compare what I have done to your version to make sure I haven't missed anything.

Does 5.8 still require the text_offset patch? The patch I have been using no longer applies cleanly to 5.8 due to a recent change: "arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely"

Let me take a stab at answering/clarifying. You are using a build and set of builds that is no longer maintained. The "aml-s9xxx" builds ended with the version you have. After which balbes150 moved to the "arm-64" builds. The "arm-64" builds (the topic of this forum thread) support more than just the Amlogic cpus that the previous 'aml-x9xxx' based builds supported. In addition balbes150 has worked to incorporate apt updates of kernel packages which really didn't exist in the 'aml-s9xxx' builds as well as other features as he continues to make improvements. So what you have installed is essentially end of the line for getting any new versions, and you would need to move to a 'arm-64' build to pick up new features and any newer kernel versions. I can't recall if you can simply upgrade the kernel package and easily move from the 'aml-s9xxx' line to the 'arm-64' builds. I have done it, but I don't remember how easy it was or wasn't. The reason it may be more or less difficult is if there are changes to the boot scripts that also occurred between what you are running and current versions that might require additional tweeking. Also a general comment overall to set expectations, the tv box builds are not official armbian builds and therefore are not supported. The work balbes150 does is a fork of official armbian, and the armbian team allows him to utilize many armbian resources (like the armbian apt repository, these forums, etc), but there shouldn't be the same level of expectation of support as there are for officially supported armbian builds. Balbes150 is one person trying to move the set of functionality he is releasing in his builds forward. Some of the rest of us on the forum try to help others, but the bulk of questions tend to get answered by balbes150 as he is the developer creating these builds. And english isn't his native language so sometimes his posts come across more harsh than they are likely intended to be.

There is a reason that the android TV boxes are so cheap. They generally lack support by the manufacturers for main line linux especially for the items on your must have list (wifi, hardware video decoding/encoding). In my opinion cheap should not be your deciding factor in what you choose to purchase as you might find that a regular SBC (raspberry pi or other, that has known support of the features you are looking for) may be the best fit and best supported option for you needs. But if you want to explore and try things out, the android TV boxes are fun to work with, and if you go in understanding that something you want won't work well on the box you end up with, you are approaching these boxes with the right expectations. For example I have four different types of boxes and wifi doesn't work on any of them. But since I primarily use them as servers it works for me to use wired ethernet. I am sure that boxes exist that meet all of your criteria, but they are not likely to be the cheap boxes and you will need to spend a bit more money to get what you want and spend a lot of time researching. One final comment about the cheapest boxes is that identically labeled boxes with the same external markings can contain very different internal hardware. My example is that I have two different TX3 mini's one has emmc for internal storage (which is what it is supposed to have) and the other has nand, unfortunately mainline kernels don't support internal nand storage so I ended up not being able to use the second box in the way I had intended. But the manufactuer of the second box was able to save a bit of money by using components that cost them less and for most people using these for their intended purpose of Android wouldn't know the difference.

You just need to get a copy of the /lib64 directory from a recent balbes150 build

I was just happy it succeeded. I will be trying other combinations over the next few days (I am doing a test from sd on the same box I ran last night right now). I'll report more data points when I can.

Success! Native build on TX3 X3 (s905x3) emmc of bionic server image took 208 minutes

So I need a new install of a current image, and I can't use an environment that has been upgraded? Correct? I will try that when I have a chance. Thanks

If your question is must you update, the answer is no. However, I wouldn't understand why you would not want to update. One of the reasons to adopt Armbian is because it should provide you with regular security updates and critical bug fixes, like any regular linux distribution on an x86 platform. Armbian isn't just a static firmware that gets something running on a box/sbc but a more mainstream linux experience with updates. Anyone who runs systems (especially exposed to the public internet) should in my opinion be concerned with security updates and fixes as a priority. Now having said that, the base ubuntu or debian will get you security updates and fixes for the majority of the system, however linux kernel updates will come from Armbian. While support for those kernel updates for Balbes TV box builds has improved significantly over the last few months, there may still be an occasional issue.

I pulled you latest Build-Armbian tree yesterday to attempt a native build on some of my hardware. I got the following error: ... DTC arch/arm/dts/rk3399-rockpro64.dtb SHIPPED dts/dt.dtb FDTGREP dts/dt-spl.dtb CAT u-boot-dtb.bin Image Type: Rockchip RK33 (SD/MMC) boot image Data Size: 73728 bytes warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] /lib64/ld-linux-x86-64.so.2: No such file or directory warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] /lib64/ld-linux-x86-64.so.2: No such file or directory [ error ] ERROR in function compile_uboot [ compilation.sh:227 ] [ error ] U-boot file not found [ uboot.img ] [ o.k. ] Process terminated (I was attempting the following build: Full OS Image, arm-64, bionic, server, standard). Should your Build-Armbian github repo be working for native builds? I haven't tried to debug this error yet, just wanted to check with you if you felt this should work given what you have checked into your github repository.

The X96 mini should contain the Amlogic s905w cpu. You should follow the instruction in the first post the following thread:

This box supposedly has a rockchip 3229 cpu, so you can either follow the instructions in this post: or this post:

I suspect your box only has 1GB ram despite what you think it has. See the following post about fake box specs: Only way to tell is to open the box and see what memory chips are installed on the board.