SteeMan
-
Posts
1053 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SteeMan
-
-
40 minutes ago, thanxx said:
Guys, how much free RAM your system shows on 4GB devices?
thanks in advance for your inputblind@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:~$ -
On 7/7/2020 at 6:39 AM, José Javier Domínguez Reina said:
With none of the tested dtb the remote control works, I would settle for being able to use the remote control to turn on the tvbox.
What can I do to make the ignition work with the remote control?
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.
-
On 7/7/2020 at 10:21 AM, Abah said:
Dear sir balbes150,
Im using s905x (2/8gb), and use 'Armbian_20.06.0_Arm-64_bullseye_current_5.7.6_desktop_20200630' build, everything work just fine but no sound from 3.5 audio/rca jack.
can you, sir, please activated this?
Thank you very much for your hard work.
Regards,
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.
-
23 minutes ago, Rajesh said:
Is it possible to do something similar from Armbian using a tool, utility or some custom program to drive this?
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).
-
55 minutes ago, iSlaker said:
I see. Yes, it makes sense.
Since I've noticed that some DTBs enable certain components while others enable others, I was hoping there was a script (or someone could write it) that would load all the DTBs in a directory and let you pick individual components in the DTBs to create a new DTB. I could write such script myself if I understood the structure of these files.
Another option could be a "DTB Viewer" of sorts. Is there such thing?
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.
-
21 hours ago, iSlaker said:
@SteeMan and @balbes150 since you guys know a lot about the inner workings of these devices, is it possible to customise these DTB files to disable components to make sure only the ones we actually need work? If so, how one would go on about it?
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).
-
8 hours ago, boxmeister said:
an image that i used wich i got from freaktab.com ( Armbian_5.98_Aml-g12_Ubuntu_bionic_dev_5.4.0-rc4_desktop_20191025.img.xz )
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:
-
11 minutes ago, boxmeister said:
apparently the ubuntu distribution this is based on is no longer maintained?
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?
-
12 minutes ago, esdcmc said:
I restarted from scratch using the same image (Armbian_20.02.0-rc1.037_Aml-s9xxx_bionic_current_5.5.0-rc6_desktop_20200205.img), reason being that in the s9xxx directory (https://mega.nz/folder/j9QSDQSQ#6WpasOlbZYIInfw6yo4phQ/folder/35ACSCjQ) there is no "Ubuntu 20.04 (focal)", as suggested by Steeman, so I don't quite know if any other image is actually compatible with my box
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.
-
22 hours ago, esdcmc said:
I followed the instructions from this forum and successfully installed armbian on an SD card (using Armbian_20.02.0-rc1.037_Aml-s9xxx_bionic_current_5.5.0-rc6_desktop_20200205.img and pinpointing the right dtb) and managed to boot on it.
Then I successfully installed homeassistant too...
great then...
except that the same homeassistant complained that Pthon3.6 is deprecated and it should be updated.
I tried to install latest Python (3.8.3) in parallel to 3.6 but there was no way of making homeassistant build correctly then.
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.
-
13 minutes ago, Teddybee said:
- I put the latest armbian focal with 5.7.2 kernel to sd card
- renamed the u-boot.sd to u-boot.ext
- box run well, shell colors all right
But after I installed the system to the emmc, the colours looks wierd again, green background on the linux shell. Can somebody help me what to do?I renamed back th u-boot.ext to u-boot.sd, but it doesn't work.
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).
-
21 minutes ago, balbes150 said:
Yes, the patch needs to be changed (I fixed it myself, but Build-Armbian hasn't been updated yet)
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.
-
4 hours ago, balbes150 said:
Ver 20200616-dev
"clean" kernel (no patch) 5.8-rc1
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"
-
1 hour ago, julian67 said:
I'm sorry you feel my posts are useless, but the headers for the armbian version I'm running are not in that list. I used your build, linked to from your first post
$uname -a
Linux aml 5.5.0-rc6-aml-s9xxx.$ apt search linux-image-current
Sorting... Done
Full Text Search... Done
linux-image-current-aml-s9xxx/now 20.02.0-rc1.038 arm64 [installed,local]
Linux kernel, version 5.5.0-rc6-aml-s9xxxetc. (there is no other aml version available on a fully up to date system on which apt update has just run.
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.
-
2 hours ago, jeanrhum said:
After those modifications, I got the same error as you. Where do you get the ld-linux-x86-64.so.2 file?
You just need to get a copy of the /lib64 directory from a recent balbes150 build
-
19 minutes ago, balbes150 said:
Hmmm, with eMMC should have been faster, I have an SD card (which is obviously slower than eMMC) on Ugoos X2 (s905x2) the build went a little faster (201 minutes of focal-server).
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.
-
20 hours ago, balbes150 said:
You can use the current system, but you need to manually add two directories\files to work with qemu (you can take them from the last finished image), see the log, it will indicate what is missing. The rest should work and install automatically.
Success! Native build on TX3 X3 (s905x3) emmc of bionic server image took 208 minutes
-
10 minutes ago, balbes150 said:
Judging from this line, you didn't use the latest Armbian Bionic image. Only they have all the pre-settings for the correct operation of the build system.
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
-
41 minutes ago, Armin said:
Now, this is OK but I need to know if I must update regulary my "Buster system" ?
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.
-
On 5/23/2020 at 11:31 AM, balbes150 said:
It would be interesting to compare the results of the build process on different TV boxes (chips) with different media.
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:
Armbian for Amlogic S905X3
in General Chat
Posted
You need to provide more details on what you are trying. What version are you trying to install (and from where did you download it). What are the steps you are attempting to install on your box?