Jump to content

SteeMan

Moderators
  • Posts

    1366
  • Joined

  • Last visited

Reputation Activity

  1. Like
    SteeMan got a reaction from CODER2127 in Installation Instructions for TV Boxes with Amlogic CPUs   
    These instructions are for Amlogic CPUs for TV Boxes. 
     
    Note: If you have previously run other distributions on the box such as coreelec the below installation will not work.  You will need to restore the original android firmware before attempting the install.  coreelec changes the boot environment in ways that are incompatible with these Armbian builds.
     
    Download links:
        Weekly Community Rolling Builds:  https://github.com/armbian/community (look for files named: aml-s9xx-box)
        or build your own image using the Armbian build framework
     
    Once you download your chosen build, you need to burn the image to an SD card.  Generally balenaEtcher is recommended as it does a verification of the burn.  Also be sure to use high quality SD cards.
     
    Once you have the SD card with your chosen build, then you need to edit the boot configuration file on the SD card.  In the BOOT partition of the SD card there will be a file /boot/extlinux/extlinux.conf, that you need to edit.  There will also be a extlinux.conf.template file to use as a reference.  You will need to add a line into the extlinux.conf file for the Device Tree (dtb) file you will be using for your box.  Place this line before the APPEND line as shown in the .template file.
     
    Basically you need to have the correct dtb for your box.  You may need to attempt to use different dtb files until you find the one that works the best for your box's hardware (there are a bunch of dtb files in /boot/dtb/amlogic/... to try depending on your cpu architecture and hardware).  It is unlikely that there will be a matching dtb file for your TV box.  The idea is to find the one that works best for your box.  This may mean that you try booting with different dtb files until you fine one that works good enough for your needs.  By searching the forums you will find information about what dtbs other users have found work best for different boxes.  Because you are booting from an SD card, you can easily try different dtb files.  The dtd files are named by cpu family.  So for example dtb files for the s905x2 cpu are named meson-g12a-*.  Below there is a table that shows the identifiers for each familiy (g12a for s905x2 in this case).
     
    Next you need to copy the correct uboot for your box.  This is needed for how these builds boot on amlogic boxes.  There are four different u-boot files located in the /boot directory:  u-boot-s905, u-boot-s905x-s912, u-boot-s905x2-s922, u-boot-s905x3
    You need to copy (note copy not move) the u-boot file that matches your cpu to a new file named u-boot.ext in the /boot directory
    So for example with a TX3 mini box that has an s905w cpu you would copy u-boot-s905x-s912 to u-boot.ext: cp u-boot-s905x-s912 u-boot.ext
    (See table below for more details on which u-boot to use for which cpu)
     
    Once you have your SD card prepared you need to enable multiboot on the box.  There are different ways documented to do this, but the most common is the "toothpick" method.  The "toothpick" method means to hold the reset button while applying power to the box.  The reset button is often hidden and located at the back of the audio/video jack connector.  By pressing that button with a toothpick or other such pointed device you can enable multiboot.  What you need to do is have the box unplugged, have your prepared sd card inserted, then press and hold the button while inserting the power connector.  Then after a bit of time you can release the button.  (I don't know exactly how long you need to hold the button after power is applied, but if it doesn't work the first time try again holding for longer or shorter times).
     
    You should now be booting into armbian/linux.  Note that the first boot takes longer as it is enlarging the root filesystem to utilize the entire SD card.
     
    After you are satisfied that your box is working correctly for your needs you can optionally copy the installation from the SD card to internal emmc storage (assuming your box has emmc). (Note: Installing to emmc has some risks of bricking your box.  Don't do this unless you feel you understand how to reinstall your box's android firmware)  You install armbian to emmc by running the shell script in the /root directory: install-aml.sh. Note: It is not possible to install into emmc on boxes with the s905 cpu (s905x, s905w, s905x2, etc however should all be supported).  It is recommended that you make a backup of emmc first.  Also be prepared if anything goes horribly wrong with your emmc install to reinstall the android firmware using the Amlogic USB Burning Tool to unbrick your device.  If you have or can find an original android firmware on the internet and you can generally (but not always) recover a bricked box using the Amlogic tool and the original firmware file.
     
     
    Mapping from CPU to uboot and dtb:
     
    u-boot-s905
    s905 - gxbb
     
    u-boot-s905x2-s912
    S905X - gxl
    S905W - gxl
    S905D - gxl
    S905L - gxl
    S805X - gxl
    S912 - gxm
    A311D - gxm
     
    u-boot-s905x2-s922
    S905X2 - g12a
    S922 - g12b
     
    u-boot-s905x3
    S905X3 - sm1
     
    Not supported or not tested
    S805 -
    S905W2 -
    S905X4 -
    S805X2 - s4
    A113D - axg
    A113X - axg
     
     
     
    Note: Followup posts in this thread should be limited to comments to improve or better understand these instructions.  Other issues should be posted as new questions in the Amlogic CPU Boxes sub-forum.
  2. Like
    SteeMan got a reaction from CODER2127 in Installation Instructions for TV Boxes with Amlogic CPUs   
    @CODER2127 in the same directory /boot.  I have updated the instructions to clarify
  3. Like
    SteeMan got a reaction from Frown in Status of Armbian on TV Boxes - Please Read First   
    Welcome to the world of Armbian on TV Boxes!
     
    TV Boxes are not officially supported by the Armbian project.  This "TV Box" sub forum is for users interested in experimenting with Armbian on TV Boxes.
     
    Overall you will be best served if you set your expectations low as to what you might be able to accomplish with your TV Box and Armbian.  Specifically you should think of your TV Box as a potential linux server - *not* as a desktop replacement.
     
    Feel free to post and ask questions in the TV Box forums if you are interested.  But realize this is a peer-to-peer forum so you may or may not get an answer.  Don't expect or demand support as there are only a handful of people that participate in these forums and they are all donating their time.
     
    Search is your friend.  There is a lot of historic information stored on this site.  Your question has likely already been asked previously.  However, a lot has changed over time and therefore be prepared for a lot of the information you find by searching the forums to be outdated and in some cases just plain wrong.  Even though that may be the case, please search the forums first before posting a question.  It shows you are willing to invest the time to do your part and makes those of us who volunteer our time to answering questions more likely to want to help you.
     
     
    Amlogic (S9xx) based TV Boxes
    1. There is a community build for Amlogic based s9xx TV Boxes - The key being community - so please contribute to make improvements
    2. A single developer (@balbes150) had worked years on getting things to the state they are.
    3. As of October 14th, 2020 balbes150 removed support for Amlogic CPUs, so that is the last active build from him
    4. Expectations should be set low (i.e. don't expect anything to work) but if you do get the box to boot, get HDMI and wired ethernet to work, you are doing good.
    5. You really shouldn't expect things like Wi-Fi, bluetooth, remote control, etc. to work.
    6. There is a very small number of people on this forum/club that are able to provide any guidance.
    7. Most likely no one on this forum owns your specific box and therefore generally can only provide vague guideance.
    8. If you get this working on your box, it will likely only be useful for server type tasks, maybe a little light graphical desktop usage, but do not expect video playback, etc.
     
    RockChip (rk3399, rk3328, rk3288, rk3228, etc) based TV Boxes
    These are probably the best supported TV boxes currently.  They have the most active developers.  Feel free to post in the Rockchip TV Box sub forums your questions.
     
    Allwinner (H6, H616, H313) based TV Boxes
    There is no ongoing effort to support Allwinner based boxes.  Occasionally a developer will respond to a question, but in general if this is what you have, you will be expected to do a lot of work on your own, so you better be comfortable doing development for these type of boards.  You aren't likely to find anything that you can just install and have work.
     
    Other Comments
    The official recommendation from the Armbian project would be to not use TV Boxes and use officially supported SBCs. Taking this approach will likely result in an easier time, less hassle, better support and likely a more fully functioning device.
     
    There are reasons you may choose to want to use unsupported Armbian on TV boxes, for example here are some of my ( @SteeMan ) reasons:
     
    1) It is a challenge and therefore a learning opportunity.  I would never have learnt to build my own linux kernels from source if I was still exclusively using x86 hardware.  If you want a challenge you will find it here.
     
    2) Price vs specs.  The Android TV boxes are built to be cheap consumer devices.  They are produced in larger quantities which drives down the per unit price.  You will generally not be able to get the same level of hardware for the same price with a standard SBC.  But that cheapness comes with - no support by the manufacturers and potentially sub-standard components.  If the manufacturers goal is to sell the lowest price box they are likely cutting corners somewhere to make that happen.
     
    3) emmc is standard.  TV boxes always come with internal storage while most SBCs do not.  Again from a price/performance standpoint having internal emmc storage vs running off an SD card is a plus.  emmc storage *should* be faster and more durable than storage on an sd card.  The caveats here being that this is one of the areas that the manufacturers may cut corners.  For example I have two TX3 mini boxes that are supposed to have 16GB of emmc memory (like the other TX3 mini boxes I have), but they were instead manufactured with cheaper nand memory for which there is no mainline kernel support.  There is no visible difference between the identically packaged boxes that had emmc vs those that came with nand, other than opening the case and looking at the physical chips on the boards.
     
    4) cases come standard.  TV boxes always come with cases, whereas for SBCs that is an extra cost.  For my uses having a case is a big improvement vs not having one.  A downside if that these cases are not necessarily well designed to provide adequate cooling.  So depending on your use case, overheating might be a problem.
     
    5) While I own both SBCs and TV boxes, I personally find the TV boxes work best for my needs (running server based software) and I enjoy the challenge of getting them running and keeping them running with the great underlying work that the Armbian project is doing to build on top of.
     
    If you have the correct expectations (set your expectations low) are looking to learn and are up for a challenge these are fun things to work with.  And I look forward to working with you on these forums.
     
     
  4. Like
    SteeMan got a reaction from mmie4jbcu in RK3566 and Armbian   
    @FuSan The recommended way to switch kernels.in Armbian is through armbian-config
  5. Like
    SteeMan got a reaction from Werner in Newbie developer question   
    Post the log of your build
  6. Like
    SteeMan got a reaction from FuSan in RK3566 and Armbian   
    @FuSan The recommended way to switch kernels.in Armbian is through armbian-config
  7. Like
    SteeMan got a reaction from Andr1k in CSC Armbian for RK322x TV box boards   
    @Andr1k  If you have one of the community nightly builds installed, you should be able to apt update/apt upgrade to the current build and then apt install linux-headers-current-xxxx.  At least that works for me, but I work with amlogic boxes, not the rockchip ones.
  8. Like
    SteeMan got a reaction from Igor in Orange Pi Zero 3   
    When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.
    It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 
     
    This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.
     
  9. Like
    SteeMan got a reaction from Werner in Orange Pi Zero 3   
    When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.
    It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 
     
    This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.
     
  10. Like
    SteeMan got a reaction from Gunjan Gupta in Orange Pi Zero 3   
    When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.
    It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 
     
    This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.
     
  11. Like
    SteeMan got a reaction from Energokom in Can't boot with 23.05 or later builds on s905x2 (g12a) or s905x3 (sm1)   
    This issue should now be fixed.  The s905x2 and s905x3 chain loaded u-boot has been updated to address the issue introduced with 23.02 and later builds.  Any build after 2023/01/31 should incorporate the fix (so the current community builds as of today have the fix) and this will appear in the 24.02 release builds.
  12. Like
    SteeMan got a reaction from mmie4jbcu in Can't boot with 23.05 or later builds on s905x2 (g12a) or s905x3 (sm1)   
    This issue should now be fixed.  The s905x2 and s905x3 chain loaded u-boot has been updated to address the issue introduced with 23.02 and later builds.  Any build after 2023/01/31 should incorporate the fix (so the current community builds as of today have the fix) and this will appear in the 24.02 release builds.
  13. Like
    SteeMan got a reaction from jock in X88 pro 10 wont boot any image   
    You should be following the instructions in this thread:
    https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards
     
    And if you have any questions or issues you should post them there.
  14. Like
    SteeMan reacted to Stephen Graf in Orange Pi Zero 3   
    @MrK I think you owe @Gunjan Gupta an apology.  There is no need for such language when people are volunteering their time and efforts, or ever for that matter.
     
    @MrK you are in the wrong forum.  Changes such as you are proposing should be done at the Linux kernel level.
     
    @MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment.  You will get more things done and with better results.  If you had been working for me I would have fired you for behaving this way. It is just too disruptive.
  15. Like
    SteeMan got a reaction from bedna in Partition table on Orange Pi 5   
    GPT is something the Armbian build framwork supports, not currently the default, but here is a list of boards that use it:
    grep -i gpt *
    armsom-sige7.csc:IMAGE_PARTITION_TABLE="gpt"
    armsom-w3.csc:IMAGE_PARTITION_TABLE="gpt"
    bananapir2pro.csc:IMAGE_PARTITION_TABLE="gpt"
    fxblox-rk1.wip:IMAGE_PARTITION_TABLE="gpt"
    hinlink-h28k.csc:IMAGE_PARTITION_TABLE="gpt"
    hinlink-h88k.csc:IMAGE_PARTITION_TABLE="gpt"
    hinlink-ht2.csc:IMAGE_PARTITION_TABLE="gpt"
    indiedroid-nova.csc:declare -g IMAGE_PARTITION_TABLE="gpt"
    jp-tvbox-3566.tvb:IMAGE_PARTITION_TABLE="gpt"
    khadas-edge2.conf:declare -g IMAGE_PARTITION_TABLE="gpt"
    mangopi-m28k.csc:IMAGE_PARTITION_TABLE="gpt"
    mixtile-blade3.wip:declare -g IMAGE_PARTITION_TABLE="gpt"
    nanopct6.wip:IMAGE_PARTITION_TABLE="gpt"
    nanopi-r5c.csc:IMAGE_PARTITION_TABLE="gpt"
    nanopi-r5s.wip:IMAGE_PARTITION_TABLE="gpt"
    nanopi-r6s.conf:IMAGE_PARTITION_TABLE="gpt"
    odroidm1.conf:IMAGE_PARTITION_TABLE="gpt"
    orangepi3b.csc:IMAGE_PARTITION_TABLE="gpt"
    orangepi5.conf:IMAGE_PARTITION_TABLE="gpt"
    orangepi5-plus.conf:IMAGE_PARTITION_TABLE="gpt"
    panther-x2.csc:IMAGE_PARTITION_TABLE="gpt"
    quartz64a.csc:IMAGE_PARTITION_TABLE="gpt"
    quartz64b.csc:IMAGE_PARTITION_TABLE="gpt"
    radxa-e25.wip:IMAGE_PARTITION_TABLE="gpt"
    rock-3a.conf:IMAGE_PARTITION_TABLE="gpt"
    rock-5a.wip:IMAGE_PARTITION_TABLE="gpt"
    rock-5b.conf:IMAGE_PARTITION_TABLE="gpt"
    rock-5-cmio.csc:IMAGE_PARTITION_TABLE="gpt"
    station-m2.csc:IMAGE_PARTITION_TABLE="gpt"
    station-m3.csc:IMAGE_PARTITION_TABLE="gpt"
    station-p2.csc:IMAGE_PARTITION_TABLE="gpt"
    xiaomi-elish.conf:IMAGE_PARTITION_TABLE="gpt"
  16. Like
    SteeMan got a reaction from krrmbn in high load, low cpu, lscpu, armbian-hardware-optimization, scaling_available_governors   
    Moved to Community Maintained Allwinner.
     
    @krrmbn Note that this is not an Armbian supported board.  It is community maintained.
  17. Like
    SteeMan got a reaction from Igor in Orange Pi Zero 3   
    I just want to add a few comments to this whole dtb overlay discussion.
     
    First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.
     
    The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.
  18. Like
    SteeMan got a reaction from pixdrift in Orange Pi Zero 3   
    I just want to add a few comments to this whole dtb overlay discussion.
     
    First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.
     
    The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.
  19. Like
    SteeMan reacted to ag123 in NPU   
    here is some 2 cents comments, if you are meaning NPUs like these:
     
    https://github.com/rockchip-linux/rknpu2
     
    - hardware interfaces are kept as trade secrets and not published anywhere
     
    1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
    it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
    and there is no hardware documentation any where about the technical details, registers etc. 
    if that at least those are published, one could possibly start coding something to test things on the NPU.
     
    then that for things like ethos-n78
    https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
    you can find some info here
    https://developer.arm.com/Processors/Ethos-N78
    but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
     
    - IO / cpu scheduling 
     
    cpu frequency scaling / governors are well documented
    https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
    https://docs.kernel.org/scheduler/schedutil.html
    https://www.kernel.org/doc/html/latest/scheduler/
    and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
    but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
    and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
    Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
     
    and if one wants to do some manual scheduling there is the plain old "nice" command
    https://www.scaler.com/topics/linux-nice/
     
    ----
    well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
     
    The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
    You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
     
    This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
     
    And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is  unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
     
  20. Like
    SteeMan got a reaction from Werner in OrangePiPC + Armbian embedded microphone issue   
    That is because this board is not supported, and you were posting in the supported boards section of the forum. 
  21. Like
    SteeMan got a reaction from billhu199 in The latest version Bookworm cannot start up when use udisk   
    Known Issue: https://forum.armbian.com/topic/30245-cant-boot-with-2305-or-later-builds-on-s905x2-g12a-or-s905x3-sm1
     
  22. Like
    SteeMan got a reaction from pixdrift in Orange Pi Zero 3   
    Also the contribute/PR process as documented in the Armbian Docs:  https://docs.armbian.com/Process_Contribute
  23. Like
    SteeMan reacted to Devmfc in Amlogic S905W2 64bit Cortex A35   
    Hi,
     
    You are posting on the Armbian forum.
    The images you refer to are not Armbian images.
    The people of Armbian don't like their forum be polluted with non-Armbian support request. I think that is quite understandable, don't you?
     
    That being said, this answer is also true for Armbian tvbox, so maybe the answer is allowed: 
     
    All those tvboxes are different, even if they look the same or even have the same 'model name' from the outside.
    Especially the wifi modules are a lottery. So you have to be lucky to get a standard supported wifi module. And otherwise you'll have to learn a lot, google a lot to get wifi working. That's the 'fun' of tinkering with those cheap boxes. If you want a working wifi and don't want to learn all that... you are better of buying a well supported SBC instead.
     
    Some pointers that might be helpful:
    decompile the dtb and look if the aml_wifi gpio's for power are the same gpios as in the DTB you use for mainline linux (sdio-pwrseq node)  sometimes it can help to lower the max-frequency property for the sdio node run ( vendev=( $( cat /sys/bus/mmc/devices/mmc2:*/{vendor,device} ) ) && echo "wifi SDIO ID: ${vendev[0]}:${vendev[1]}" )  to get the driver vendor ID and device ID. If that doesn't work, previous two points are probably not ok. (Or wifi is not on SDIO bus, but is not very likely) (alternatively) open the box, look for the wifi markings and search google for the linux driver source and compile that driver Have fun!
     
  24. Like
    SteeMan got a reaction from Victorhtf in Installation on new tx3 mini fails   
    There is no such cpu.  Can you specify the cpu you have?  There are many different versions of boxes labeled tx3 mini, so you need to be specific.  Pictures of the motherboard would also be helpful.
  25. Like
    SteeMan got a reaction from ajuyg in Booting issues with Vontar X3   
    You need to find the correct Android firmware for your device and reinstall it according to the instructions for that firmware (usually USB burning tool)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines