SteeMan
-
Posts
1654 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SteeMan
-
-
@supersmurfs Welcome to the Armbian TV box forums. I want to thank you for your interest and apparent willingness to dig in and learn.
-
Most of my TV boxes are amlogic based. I just bought an H6 box but haven't had time to do much with it other than to boot an armbian build on it. Armbian booted on the box but networking didn't work, so I need to find some time to look into that when I get a chance. I may be reaching out to you once you get your allwinner boxes up and running
-
The first place to start is by reading the documentation: Armbian Developer Guide. The developer guide walks you through the armbian build process. The entire armbian build process may be more than you are looking for (not knowing what changes you are looking to make), but with an overall understanding of the armbian build process (simply being able to rebuild the image you are already running) you will likely be able to figure out a path forward for your needs, or at least be able to come back to the forums with a more specific question based on greater understanding of the system.
-
@Clonazepunk Welcome to armbian. I was just reading your recent posts and it sounds like you have some good technical skills and a desire to help others. A combination that is in limited supply. As you are new to armbian, if there is anything I can do to help your learning curve please reach out to me. The TV Box community needs people like you willing to help others. It seems that you have an interest in both rockchip and allwinner TV boxes. While Jock and other provide great support for rockchip there really isn't anyone currently supporting allwinner. So if you are looking for a challenge...
Again if you have any questions for me please reach out to me either in the forums or through PM.
-
-
-
Your question was already answered the first time you posted your question.
There is an entire thread dedicated to discussing how to install armbiian on an rk322x tv box: https://forum.armbian.com/topic/17979-help-can-i-install-armbian-on-tv-box-with-r329q-v30-board/?tab=comments#comment-123847
This is now the third the you are asking the same question. It you ask a fourth time, I will consider you as spamming the forum and proceed accordingly.
-
Moved to proper forum for a TV box question.
Please read the FAQ entry: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
Then search the forums for previous discussions on this topic.
-
@Wizzard In searching through this thread and the forums, I can't see anyone reporting to have tried installing on your model. Since no one has responded to your post, it is unlikely anyone around here has your model of box and therefore unlikely to be able to help you out. There are hundreds of different TV box models each with different components which makes support for the vast majority nearly impossible. There is likely information in this thread that could help you, but unfortunately you are likely on your own to sort through it and try out potential solutions to get your box working. One thing I noticed in this thread that may be helpful to your case is a comment that mentioned replacing the uboot on the armbian image with a libreelec uboot. Since you indicate you can boot libreelec that path sounded relevant to your situation. Unfortuantely I don't own any rockchip boxes and therefore am of little help beyond providing pointers to others efforts.
-
Your question is off topic for these forums as we deal with running armbian on SBCs and TV Boxes. Not with apks and android.
-
14 minutes ago, masteripper said:
OK...restoring means flash ?
yes
-
1 hour ago, masteripper said:
Thanks @SteeMan for the assistance.. given the fact that I switch MicroSDs and the one holding the Manjaro each time boots multiboot is enabled... what do you think ?
The manjaro version of multiboot is enabled but that has nothing to do with the armbian version of multiboot. Each distro does multiboot differently and they are not compatible. You must restore the base android firmware to get a good known environment before attempting armbian. I don't know how many times I have to say the same thing. If you want help, you need to follow the instructions.
-
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.
-
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.
-
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.
-
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.
-
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.
-
-
How were the image files that you would like to restore created?
-
@Geekati Please first read:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
Then read the following thread which should be relevant for your needs:
https://forum.armbian.com/topic/16859-allwinner-h6/
-
Please first read:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
Then read the following thread which should be relevant for your needs:
https://forum.armbian.com/topic/16859-allwinner-h6/
-
Since this is an allwinner H6 based box, moving to the allwinner TV box forum
-
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.
-
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).
Can anyone explains what are the steps for making a TV box works with armbian?
in General Chat
Posted
This comment is likely superceeded by balbes and jock's posts, but I wanted to just provide my thoughts on the android dtb issues.
The way I like to think about dtbs is they are glue code between the kernel and the hardware. We often think of them only from the perspective of the hardware, which once a box is built the hardware doesn't change (although boxes can change over the course of different manufacturing runs providing different board revisions). But the kernel is an evolving code base and even though the hardware may be fixed, the dtb glue may need to change over time as the kernel code changes. Thus technically dtbs are kernel version specific (but in practice the changes in the kernel generally are not significant over smaller periods of time).
However.... When it comes to android kernels two factors come into play, one is that android kernels tend to be highly forked/patched from mainline kernels and second, android kernels tend to be based off very old kernels. So for example an android 4.4 based kernel is really a 5 year old kernel, and a lot has changed in the kernel over a 5 year period.
Also, making this more complex is that fact that sbc/tv box support has only been added to mainline kernels fairly recently. So older android or legacy kernels that were supported were highly patched kernels.
Armbian is generally focused on current mainline kernels (after all that is where the future support will all take place), and therefore a 5.10/5.12 kernel is very different in how it supports sbc/tv box hardware than a 4.4/4.x legacy/android kernel.
The end result is to not expect an android dtb to work with a mainline kernel. That doesn't mean that there isn't a lot to be learned from an older dtb file, but the process is much more complicated than simply getting the old andoird dtb and using it on a mainline kernel and expecting it to work.