SteeMan
-
Posts
1461 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SteeMan
-
-
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:
-
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.
-
1 hour ago, Armin said:
root@arm-64:~/tmp# cd /dtb
I should have looked a bit closer at what you did, you were root so that wasn't the issue. You really need to learn basic linux commands. 'cd dtb' is what you wanted to do, not 'cd /dtb'
-
1 hour ago, Armin said:
I can not access to dtb directory
You need to either be root (sudo su root) or sudo the actions you want because only root has permissions on the files in /boot
-
2 minutes ago, Armin said:
I suppose that witht the commande mount /boot is from SD Card and not from eMMC ?
So,
How can I copy meson-sm1-sei610-ethfix.dtb from SD Card to same folder on eMMC ?
Yes while running from sd card you should be able to do:
$ mount | grep mmc
/dev/mmcblk1p2 on / type ext4 (rw,noatime,errors=remount-ro,data=writeback)
/dev/mmcblk1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/mmcblk1p2 on /var/log.hdd type ext4 (rw,noatime,errors=remount-ro,data=writeback)(If your device is standard you should see that your sc card is device /dev/mmcblk1 with two mounted partitions p1 = /boot and p2 = /)
$ ls /dev/mmcblk*
/dev/mmcblk1 /dev/mmcblk1boot1 /dev/mmcblk1p2
/dev/mmcblk1boot0 /dev/mmcblk1p1 /dev/mmcblk1rpmb/dev/mmcblk2 /dev/mmcblk2boot1 /dev/mmcblk2p2
/dev/mmcblk2boot0 /dev/mmcblk2p1 /dev/mmcblk2rpmb(Again if your device is standard you should see both mmcblk1 and mmcblk2 - with mmcblk2 being your emmc)
$ mkdir tmp
$ sudo mount /dev/mmcblk2p1 tmp
(mount the first partition of mmcblk2 to ./tmp - this will mount the emmc boot directory to tmp)
$ cd tmp
$ ls tmp
(you should see the contents of your emmc boot directory here, now you can edit the uEnv.txt file, copy to this directory any dtb you wish, etc)
$ umount /dev/mmcblk2p1
(un-mount the disk when you are done, shutdown, pull the sd card and reboot to emmc)
-
4 minutes ago, Armin said:
Therefore, I will try your suggestion: meson-g12a-x96-max-rmii.dtb
After booting on SD card:
- How can I test deeply the ethernet connection (before to transfer the installtion on the eMMC) ?
- When this is OK, Can I make directly the installation on the eMMC over the previous one ?
Actually my original suggestion a few posts ago was to try all of the g12/sm1 dtbs and find the one that works best for your hardware.
To test the different DTBs, you will need to use the working sd card you have from earlier. Edit the uEnv.txt file and try rebooting with that sd card using the different dtb. When you find the dtb file that works best for you, you can either reinstall that entire environment to emmc by using the install-aml.sh script (but doing so will overwrite everything you have on emmc), or while running from the sd card, mount the /boot partition on the emmc and edit the uEnv.txt file on the emmc directly.
The command you are using to set the network speed (ethtool -s) does not persistently make that change, so you will need to do that after every reboot. I'm sure you could google and find a way to make that change persistent, but if you can get it working without manual changes it would be better for you.
-
4 hours ago, Armin said:
Force the Ethernet speed to 100Mb
Have you tried all of the dtb files to see if any of them support your ethernet setup without needing to make manual changes? From above it looks like you are using: meson-g12a-x96-max-no-cvbs.dtb. I would suggest you try meson-g12a-x96-max-rmii.dtb which is a 100Mb ethernet version of the meson-g112a-x96-max.dtb file.
Good to see that you have made overall progress today on your box.
-
15 minutes ago, MadOp said:
- stable WiFi,
I would say that this will be the most difficult requirement to meet. It is very hit and miss (my experience is mostly miss) whether you will be able to get wifi working on any particular box. If you are able to, use wired ethernet and you will be much more successful, or alternatively purchase inexpensive usb wifi dongles that have linux mainline support. In addition to the poor support by the wide variety of wifi chips in these boxes by mainline linux, you can purchase identical looking boxes that have different internals, so just because you have something working on one box (or someone else does) doesn't mean it will also work for another identical looking box because it has a different wifi chip inside.
-
6 minutes ago, Armin said:
cd /boot
sudo cp u-boot.ext u-boot.sd
cd
sudo /root/install-aml.sh
You should not need to do anything with the u-boot file at this point as the u-boot.sd file should already exist (as long as you copied instead of moved the file earlier)
All you should need to do is:
sudo /root/install-aml.sh
Although what I do is become root and run from the root directory:
sudo su root
cd root
./install-aml.sh
-
4 hours ago, Armin said:
1. Select a firmware from May into link RK_AML_AW:
for example Armbian_20.05.4_Arm-64_bionic_current_5.7.0-rc5_desktop_20200516.img
2. Burn it on the SD Card with Etcher.
3. Edit uEnv.txt to select only one DTB file (g12 or sm1) into Amlogic section
(the other DTB files into the other sections needs to be place in comments with # ?)
4. Rename u-boot.sd to u-boot.ext
5. Try to boot wtih the SD card on the box
If this is OK, next step will be to install it on the eMMC.
1. Select a firmware from May into link RK_AML_AW:
for example Armbian_20.05.4_Arm-64_bionic_current_5.7.0-rc5_desktop_20200516.img
>> Yes
2. Burn it on the SD Card with Etcher.
>> Yes
3. Edit uEnv.txt to select only one DTB file (g12 or sm1) into Amlogic section
(the other DTB files into the other sections needs to be place in comments with # ?)
>> Yes comment out all APPEND and FTD lines except the one for the DTB you are testing, and the AML boot line.
4. Rename u-boot.sd to u-boot.ext
>> Do not do this at this stage, keep it simple and see if you even need this.
5. Try to boot wtih the SD card on the box
>> When you boot you need to enable multiboot (either through the "toothpick" method or the android update method.
If this is OK, next step will be to install it on the eMMC.
>> Then you should be testing all the features you want/need, perhaps trying with different DTBs to see if others work better or worse, then test with the color fix (cp u-boot.sd to u-boot.ext if you need).
>> Only when you are happy with how everything runs, would I try to install to emmc.
>> The idea is to do the setup step by step testing along the way so you know when things in this multistep process are not working for your box.
Single Armbian image for RK + AML + AW (aarch64 ARMv8)
in General Chat
Posted
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.