Jump to content

SteeMan

Moderators
  • Posts

    1653
  • Joined

  • Last visited

Posts posted by SteeMan

  1. @robertoenr Based on what you described you have done, you a doing a lot of work you don't need to.

    First off, the Oct 14, 2021 Balbes images already have the u-boots from hexdump for the s905x (and therefore s905w) cpu.  The one you downloaded and are trying is the same as what is already in the image.  My comments above all talk about the s905x2 and s905x3 which don't have hexdumps u-boots in the balbes images.

    .

    My strong recommendation is to do all your testing on an SD card install, get that working the way you want, then copy the working environment from SD card to emmc using the install-aml.sh script.  Experimenting with u-boots and kernels directly in the emmc environment is asking for a bricked box, as any number of simple mistakes can lead to the box not booting correctly.  If you make those same mistakes on and SD card, you simply pop it into another machine and edit/undo what you did and try again.

    .

  2. 4 hours ago, lcapriotti said:

    tks! There are two possible candidates: install-aml-s905-emmc.sh and install-aml.sh, which one shall be used on our box?

    The install-aml-s905-emmc.sh is for boxes running the s905 cpu

    The install-aml.sh script is for boxes running all other s905?? cpus (s905x,s905w, s905x2, s905x3, etc)

    I don't have any s905 based boxes so I have only ever used the install-aml.sh script for my s905w, s905x2 and s905x3 boxes.

  3. @jbolanosg I haven't had time to test hexdump's u-boots much yet.  But the general idea is that you replace the /boot/u-boot.ext file with the appropriate hexdump uboot (g12a-u-boot.bin (s905x2) or sm1-u-boot.bin (s905x3)).  Once you verify that works with a 5.9 kernel, then you can attempt to use a 5.10+ kernel.  The testing I have done in the past was all from SD card.

    BTW, the ethernet issue I was seeing I believe is this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/amlogic?h=v5.11-rc7&id=19f6fe976a61f9afc289b062b7ef67f99b72e7b9 which was just fixed in 5.11.0-rc7, but hasn't yet been fixed in 5.10.y.  I am in the middle of testing that this does or doesn't fix my ethernet issues under 5.10

  4. @Janaboy What version of the kernel where you previously running? If you were running an old vendor legacy kernel, there are enough differences between the legacy kernels and mainline kernels that it could explain the dtd issues you are seeing.  As for the dtb's the general idea is to try them all and use the one that works best for your hardware.  In your case try all the meson-gxbb* dtbs.

  5. 8 hours ago, lgranie said:

    I did not manage to run a 5.10 packaged kernel on my x96max.

    The chain loaded u-boots for s905x2/x3 in the balbes 10/14/2020 build do not support kernels greater than 5.9, due to the changes in the 5.10 kernel.  Also there is a change in 5.10 that breaks ethernet on these cpus as well in some cases.

     

    To fix the u-boot problem you should use the following u-boots from hexdump: g12a-u-boot.bin (s905x2) and sm1-u-boot.bin (s905x3) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 (renamed to u-boot-ext).

     

    If you run into the ethernet issue, that should be solved by reverting with this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/amlogic?h=v5.11-rc7&id=19f6fe976a61f9afc289b062b7ef67f99b72e7b9  (This fix was just rolled into 5.11.0-rc7 this past week, it hasn't made it into 5.10.y yet)

     

    I am in the process of testing all of the above to verify that I can get 5.10 and higher kernels working on my own s905x2 and s905x3 boxes.  So the above may or may not be correct until it is verified.

     

  6. Have you reenabled multiboot from your new SD card (i.e. pressing the reset button during power on, or one of the other methods mentioned in the forums).  The booting procedure is different from your old install to the new one.  You would need to install the new multiboot setup for the bootloader to know where things are in your new SD card.

  7. Let me add my limited knowledge here.  Note that the following comments only apply to amlogic CPUs.  The 'chainloading' of u-boots is designed to utilize the original u-boot that came on the device (stored in emmc) to start booting.  Then after the original u-boot has initialized everything, the secondary u-boot (the chain loaded one) is started to continue the process and load the linux kernel, ramdisk and dtb and launch the linux kernel.  This secondary chain loaded u-boot is stored in the /boot directory and named u-boot.ext.  Thus the installation step to rename the appropriate u-boot file to u-boot.ext (this file could on either SD, USB or emmc depending on where the installation is running from.

    The reasons for doing things this way are to try to simplify things such that multiple different TV boxes can be supported.  Theoretically each TV box should have its own custom u-boot to fully boot correctly.  By using the existing manufacturer shipped u-boot we avoid having to build a hundred different u-boots for each device.  The problem is that these original u-boots are buggy and old so they don't support the latest u-boot functionality - like using hdmi output during the boot process.  The chain loaded u-boots are using recent u-boot source code and therefore are better.  Because the hard work of bringing the system up (memory, cpus, other devices) has already been done by the base u-boot, the chain loaded u-boot has a lot less to do and hopefully can be more generic and support multiple different boxes with one u-boot build (per CPU).

  8. 3 hours ago, lgranie said:

    I want to do this so when I install linux-image-current-meson64 or other kernel package I do not have error because it looks like the package's script is expecting a ext3/4 partition.

    The fix for this would be on the armbian side (for the linux-image-current-meson64 package).  It is a one line fix in the postinst script.  I plat to submit a PR for this fix when I get a chance.

  9. 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.

     

     

  10. @Matt Neapolis You posted your question in a forum for submitting bug reports.  I have moved your post to the TV Box club forums.

     

    To try to answer your question, you have the wrong tool for the job.  You really need a SBC not a TV box.  Controlling outside devices is generally done via gpio pins which isn't something TV boxes expose because that isn't what they are designed for.  A proper SBC will have pins to your hearts content to interface with other devices.  Having said that, while I've never heard of anyone using a TV box to do what you are asking, that doesn't mean it isn't possible.  Someone around here may have other knowledge.

  11. Moved post to the correct forum. 

    @Craig Jameson My first word of advise is to read: https://forum.armbian.com/topic/16407-please-read-first

     

    The instructions you are looking for are in the first post of the thread you reference.  Note the warning in that post that says if you have used coreelec you will need to restore your box to original firmware before being able to use armbian as coreelec messes with the boot loader in way incompatible with the armbian approach.

  12. Please read: https://forum.armbian.com/topic/16407-please-read-first

     

    What you are currently running is a vendor kernel - i.e. a heavily patched kernel that isn't maintained.  The builds you are trying to use are mainline kernel based.  Because of lack of vendor support, the mainline kernels while maintained and supported are often missing functionality that existed in the vendor kernels.  Add to that the vendor kernels were written to run android not general purpose linux.  The last comment I would make is that because the mainline kernels are distinct from the vendor kernels, the dtbs are not compatible across them as a lot has changed between 3.14 kernel days and 5.10 kernel days.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines