Jump to content

SteeMan

Moderators
  • Posts

    1998
  • Joined

  • Last visited

Posts posted by SteeMan

  1. 33 minutes ago, masteripper said:

    what about the subquestion...if the multi boot persists

    Enabling multiboot is something that only should need to be done once, assuming it is done correctly.  It is persisted in the uboot environment stored on emmc.

    Having said that, I have experienced cases where for some reason on some boxes the uboot environment gets reset to the default and multiboot does need to get re-enabled, but that is a rare occurrence, nothing I have ever seen happening on every boot.

  2. 29 minutes ago, masteripper said:

    I assume that when you run a - whatever - distribution from  if you stay on the microsd no charges to the underlying system is performed...am I wrong ?

    Your assumption is incorrect.  The 'multiboot' changes the uboot environment stored on the emmc, even if you are trying to run something on sd.  The is the whole point of 'enabling multiboot' without the changes to the base uboot environment the board doesn't know how to boot from the sd card.  Those changes to the base uboot environment are different across different distributions and therefore the requirement to restore back to a known base with the original android firmware.

  3. When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment.  The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase.  Instead they are likely to purchase one or a few to evaluate first.  That evaluation is not going to happen in a rack mount, but instead will happen on a desktop.  Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.

    In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work.  One example of this is an hdmi port.  While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop.  Another example is cooling as mentioned in the above posts.  I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.

     

    My ideal feature list would be:

    1gbit POE ethernet port

    4GB ram

    32GB emmc (or more optional)

    good external storage options (m.2 or other)

    hdmi port

    2 or more usb ports (at least one being usb3)

    power port for non POE usage

    optional case for desktop use with good thermals

    optional rack mount with good thermals

     

    The two things I think it shouldn't have:

    - no wifi/bluetooth

    The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.

    - no SD card

    The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media.  You only need another option to install/update the internal emmc and usb should be sufficient for that.  The sd support then just becomes an added cost with no real long term need.  It does require that booting from usb be well supported by the firmware.

     

    Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.

     

    My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.

     

    Finally I'll mention price.  In my opinion you likely need the above described board at a price point no more than a RaspPi.  Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful.  Price will to an extent drive the evaluation process.  If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.

     

  4. 32 minutes ago, geekinlinux said:

    i have h616 t95 max with me, 
    downloaded the images from your link and flashed with balenaetcher, device is not booting.
    it boots into tv box without sd card i see led light saying `boot` but with sdcard i see nothing, ami following right way can you help me fix it.

    thanks.

    This thread is for the allwinner H6 cpu.  Your box as you mention has the H616 cpu.  Different CPU requires different builds.  There is no armbian working build for h616 cpu as of now.  Some work is happening on it, but it is likely a year out from being supported.

  5. Since you mention attempting to install other distributions you need to follow the note in the instructions I pointed you to:

     

    "Note2: 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 attemping the install.  coreelec changes the boot environment in ways that are incompatible with these armbian builds."

     

    You need to restore a clean original android firmware before attempting to install the armbian build.  Each distribution will change the boot environment in different and (unknown to us) ways.  So in order to be successful you need to restore your box to a clean known state before attempting an armbian install.

     

     

     

  6. First off start by reading the two TV Box FAQ items:

    https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first

    https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus

     

    Then it would be helpful to provide any additional information you have.  Like what you are seeing happening when you boot with the armbian sd card and press and hold the reset button.

  7. 13 minutes ago, Ngo Thang said:

    But why I check in CPU-Z app in its original Android firmware, CPU-Z still shows 4G/32G ?

    Sometimes disreputable manufacturers will modify the kernel in the android firmware to provide false information. (easy way to cut costs by not actually including the memory/storage advertized).

  8. 5 minutes ago, Raulin said:

    Tengo una caja Tv Box, con esta placa queria saber si es posible instalar armbian...y si es asi como es el precedimiento de instalacion......gracias por su ayuda...

    "I have a Tv Box, with this board I wanted to know if it is possible to install armbian ... and if this is how the installation procedure is ...... thanks for your help ..."

     

    The armbian forums are in english.  Please use google translate.

  9. @drookie Welcome to the world of impossible to support tv boxes.  As you mention the hardware of these two otherwise similarly labeled tv boxes is different.  /The dtb file is what provides the mapping from the hardware to the linux kernel.  So what you really need are two different dtb files for the two different boxes.  But without the support of the tv box manufacturer providing the necessary information on their hardware it is very difficult to figure out the correct dtb for a box (let alone a hundred different boxes from different manufacturers all with slight differences in their hardware).  There isn't really anyone currently involved in this project that has the skills/time/desire to work on this nearly impossible problem.  This is why the TV Box FAQ item (https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first) says to set your expectations low.  It sounds like you do have a mostly functioning box so consider yourself better than many.  We could always use more contributors around here.  If you have the skills and time, you could learn a lot by trying to research and update the dtb for your hardware and contribute back to the community your work.

     

  10. If you want help (and both jock and I are here to help you), you do need to provide some more information.  Things that would be helpful include:

    1) What are you trying to accomplish?  (people don't just change kernel config files and rebuild kernels for no reason)

      - what changes do you want to make and why?

    2) What experience do you have in building kernels?  Have you built an x86 kernel before?

      - knowing where you are starting from experience wise helps us give you the appropriate level of information

     

    I started a year or so ago about where I think you are.  My goal was to get more regular kernel updates following the linux mainline sources.  I spent a couple of months reading a lot of threads in these forums about others who had done similar things and over time built up my knowledge so that I am now able to build mainline kernels for both my test and production boxes. (I just this morning updated one of my test boxes to the just release 5.12.0 kernel).

    As jock mentioned above the overall process is more than just compiling and building a kernel image.  You also need to understand the boot process so that your kernel is correctly invoked by the boot process and then you also need to understand enough about dtb files so the kernel knows how to interact with your hardware.

     

    From some of my notes from last year here is a thread I found useful in my learning process:

     

     

     

     

  11. @cuker Some of the amlogic u-boots that were in balbes150 builds come from the work of hexdump. (I don't know if balbes150 further enhanced them or not).  Look at the following thread for hexdump's repositories and building instructions

    https://forum.armbian.com/topic/16753-chainloaded-uboot-images-for-amlogic

    I have rebuilt some of these from source to see if I could, as I don't generally like using binary code that I don't know the origin of.

  12. @jacinto69 Please read the two TV Box Club FAQ items:  https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first and

    https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus

    .

    Then after being sure you are following the correct installation steps, please provide more details on your installation, like what dtb files you have tried, what u-boot.ext file you are using, etc.

  13. 1 hour ago, Jackchen said:

    Hello, I am currently using your armbian 3.10.108 image, but I want to build Retroarch in it, and found that the Mali GPU driver is missing, I want to ask, is there any way to solve it

    Please read the FAQ entry: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first

    There are a couple of comments in that post that are relevant to your question.  1) balbes is no longer working on amlogic cpus, 2) the current state of the TV box code (espeucally for amlogic) is suitible for server use only, don't expect much graphical support to be working.  Also in a comment just a few posts ago, balbes expressed his opinion that he doesn't work with proprietary binary closed source code (like the legacy mali drivers).  The open source drivers are only becoming available on current kernels, so there isn't anything except closed source support for your 3.10 ancient kernel.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines