SteeMan

Members
  • Content Count

    98
  • Joined

  • Last visited


Reputation Activity

  1. Like
    SteeMan got a reaction from thanxx in Armbian for Amlogic S905X3   
    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:~$
  2. Like
    SteeMan got a reaction from balbes150 in Armbian for Amlogic S905X3   
    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).
  3. Like
    SteeMan got a reaction from usual user in X96 Air (4/32 Go) and Wireless driver for RTL8822cs   
    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).
  4. Like
    SteeMan got a reaction from Teddybee in Armbian for Amlogic S905X3   
    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.
  5. Like
    SteeMan reacted to balbes150 in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    1. I don't owe anything.
    2. if you Want to get detailed documentation and dedicated resources for posting materials for download, pay 5000 to donate Armbian.
    3. I have a very negative attitude to those who use someone else's development for free (in which a lot of work\money\time of different people is invested), absolutely do not help this project in any way and at the same time make claims.
  6. Like
    SteeMan reacted to usual user in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    A devicetree is basically a standardized representation of the schematic of a board design. It provides parameters about the components used that drivers need to operate, or tell the kernel which driver to use in the first place. You can only recycle a DT if your device is a exact clone of an original device. Otherwise non matching components won't function properly.
    This is not the right way to proceed. This is as if you are using a disassembly of a binary program to rewrite the entire program. When compiling the original sources, information has been lost that cannot be reproduced during disassembly.
    The proper way is:
    You are the board designer with access to the reference documentation of all used components.
    You learn the syntax of DTS files.
    You write a board specific DTS with mainline binding documentation as reference.
    If your board design is based on e.g. a reference design from an SOC provider, you may be able to use his DTS as a template where you have only to adopt your modifications.
    When this is done, contribute it to mainline and it will work for all your customers out of the box. Of course, the kernel build must have enabled all required drivers.
                                 
    But I guess you are not in this situation So you have to do reverse engineering:
    Collect as many board details as possible.
    Learn the syntax of DTS files.
    Write a board specific DTS with mainline binding documentation as reference.
    You can use the original sources of meson-gxl-s905x-khadas-vim.dtb as a template and customize the differences (board model, compatible, Wi-Fi bindings, ...).
    Android DTs can only be used for hints, the bindings used are most likely proprietary and do not match those of the mainline kernel. Copying them over will not magically insert code into the kernel drivers to make use them.
    When this is done, contribute it to mainline and it will work for all. Armbian will probably pull it for early adoption if you provide a PR, as bringing it to mainline may take some time.
  7. Like
    SteeMan got a reaction from jock in Good Box for Linux?   
    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.
  8. Like
    SteeMan got a reaction from amirul in Good Box for Linux?   
    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.
  9. Like
    SteeMan got a reaction from Werner in Good Box for Linux?   
    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.
  10. Like
    SteeMan got a reaction from balbes150 in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    Success!  Native build on TX3 X3 (s905x3) emmc of bionic server image took 208 minutes
  11. Like
    SteeMan got a reaction from balbes150 in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    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.
  12. Like
    SteeMan got a reaction from balbes150 in Armbian for Amlogic S905X3   
    You have done a lot of things wrong and not mentioned many other important steps.  For example you are mixing and using pieces of old information that are unnecessary  at best, or problematic at worst.  For example don't use the files from NicoD, as everything you need is incorporated into the current RK + AML + AW builds.  You are also mixing builds, the build you started with is from February and it is now May.  The multiboot process evolves overtime and what got installed into your emmc by multiboot when you first tried may not be compatible with current builds.  Most importantly the key to success is the dtb file.  In your initial post you don't even mention what dtb you are trying.  The general rule is that you should try every dtb file compatible with your cpu (which in the case of the s905x3 would be all g12 and sm1 dtbs) to find the one that works best.
    Here is my recommendation: start fresh.  Start simple then build from there.  By this I mean don't worry about things like the color issue at all at the beginning, as that may not even be an issue for you.  Even if you have the color issue, the system is still usable.  Then once you have a baseline knowledge of what works and what doesn't, then try to get the remaining items working for your needs.  Be prepared to go back to a clean environment (i.e. back to fresh android firmware) multiple times in this process.
    I have a s905x3 based TX3X3 that I am now running happily (as a server without wifi or bt) but I have needed to restore the android firmware multiple times and started over when things just stop working for no apparent reason after I made changes to the box.  
    Finally,  set your expectations low.  You should be able to get a box that boots, has ethernet, hdmi and can be used as a server.  Everything else (wifi, bt, usable desktop, etc) is something that you may get with luck and a lot of hard work.  Unfortunately that is the situation with armbian on these android tv boxes since the device manufacturers  provide no support (in terms of source code or documentation) on their products so there is very little ability to get things working with armbian in any supportable way. (especially true with aml based boxes which is why balbes150 is no longer investing time into their support).
  13. Like
    SteeMan got a reaction from balbes150 in H96 Max dead - Can I revive it ?   
    I would repeat what balbes150 said above.  For working with amlogic based boxes, I would highly recommend that you get familiar with the USB Burn tool.  I have unbricked many a box with this after experimenting with something that failed.  To use this tool you will need an original android firmware image for your box from the manufacturer.  Generally a quick google search will lead you to one.  Then for less severe problems having a backup of the emmc using the ddbr tool within armbian will give you an easy mechanism to restore your emmc as long as you can still boot armbian from usb/sd.  I have a set of android firmwares for all the amlogic boxes I own and periodically make ddbr backups when I have something on the emmc that I don't want to lose.
  14. Like
    SteeMan got a reaction from Seb_Lz in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    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.
  15. Like
    SteeMan got a reaction from aaditya in Infrastructure needed for releasing new kernels for Armbian for TV Boxes   
    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.
  16. Like
    SteeMan reacted to Igor in What is status / method for usable linux-headers?   
    Agree! I am sick and tired reading this every fu***** day: "we want Armbian on XXX Please help", "i need instructions how to ..." "do this" There is a forum https://forum.armbian.com/forum/22-board-bring-up/ full of insane demands like "make Armbian on this and that board", but nobody asks themselves how much does this costs and who (will) pay(s) this shit ... !?
     
    The other day one come to IRC starting to ask me if I can explain him how TV boxes boots. I said, we don't support that, but he didn't take this as an legit answer. And the more I explained that I don't know and even I knew I would not write manuals because he asked, the more aggressive he got ... he - while abusing my time - accused me (!) for hiding the information about boot processes ... amazing.
     

    I estimate core crew makes 30-50h every day to keep this project running which means even with 10.000 USD per device we are not covered, but we can at least silence insane wishes and demands.
     
    We have to work on this problem properly.
  17. Like
    SteeMan reacted to balbes150 in What is status / method for usable linux-headers?   
    Everyone likes to say one word "give" and always for free (all free). Give a new core, and all the functions will work in it. Give support to all the existing equipment in the world and make sure that it turns on automatically, without any settings. Give me a new loader. Give the installation system to eMMC and so that you need to press one button, and better from a mental order. Give full-screen 4K video playback on any shit. Give the perfect job to all the shit that is produced and sold for $ 10-20. Give the source code, and that they would work immediately on the same command and without errors. Give answers to all your questions and be sure to answer everyone personally and in detail. And most importantly, everyone wants it for free and immediately. For everyone who wants to get it-there is a tariff, pay $ 10,000 and you will get full support for your TV box model for 1 year. 
  18. Like
    SteeMan got a reaction from balbes150 in What is status / method for usable linux-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.
  19. Like
    SteeMan got a reaction from psxsnake in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    Is your system clock correct? 
  20. Like
    SteeMan got a reaction from amirdelta in X96 (S905x) - driver RTL8189ES and RTL8188FTV for Octoprint and Klipper 3d printer   
    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.
  21. Like
    SteeMan got a reaction from balbes150 in how to install armbian to eMMC   
    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.
  22. Like
    SteeMan got a reaction from psxsnake in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    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.
  23. Like
    SteeMan got a reaction from manuti in Building and installing custom kernels   
    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.
     
     
    build-debs.txt
  24. Like
    SteeMan got a reaction from XTL in The list of models that are running Armbian (Amlogic, Rockchip, Allwinner etc)   
    H96 Max X2 (with S905X2 cpu) 4GB Ram ad 32GB Emmc
     
    I purchased this box thinking I was getting an X96 Max (the naming of all these different boxes is very confusing).  But it turns out that it works well with current builds of balbes150's Armbian.  It works with the meson-g12a-x96-max-rmii.dtb.  It works well installed to eMMC.  The wifi does not work, and I haven't tried bluetooth or hdmi audio.
  25. Like
    SteeMan got a reaction from balbes150 in Armbian for Amlogic S9xxx kernel 5.x   
    You will need to build the .deb files from source in order to upgrade.  I have been doing this for the last couple of months and things seem stable enough for this work fairly smoothly.  You will need to use the build environment fork from balbes150's git repository (https://github.com/150balbes/Build-Armbian).  It is quite simple to do a build from source if you have an intel based machine running Ubuntu18.04.  (Note there is one mistake in the instructions, when is says to "cd build" after "git clone https://github.com/150balbes/Build-Armbian", it should say "cd Build-Armbian")
    Once you have built the .debs you can use apt to upgrade them in your installation.  Look at what packages you have installed and upgrade to the newer versions you have built.
    I would recommend doing a image backup before you attempt the upgrade until you are comfortable with the process.  To make a backup, burn an Armbian image to SD or USB, boot from it and run the 'ddbr' command to backup the eMMC. Then you will have a backup image to restore from if something goes wrong during an upgrade.