Werner

Suppose we need to dig in to kernel config , thus " KERNEL_CONFIGURE=YES "
and see what is going on there ... maybe later when I had some sleep ...

If you could provide this as patches for Armbian to include into the building process it would be appreciated

Hi,
 
shame on me!
 
Your'e completly right, this image works with another SDCARD.
The broken one was out of the box and looked good, nothing seemed to be wrong.
 
I apologize very much for any inconvenience and would like to thank you for the quick help.
 
Best wishes
Paul
 
 

How?

We now do have a documentation about all the IRC related stuff and its features. Check it out: https://docs.armbian.com/Community_IRC/

Images has been fixed (v20.05.4 ->). Try now.

Not sure which country you are but on amazon you can find the following good replacement : https://www.amazon.com/dp/B07NCG1P8X
You might have to look for the same product ref. on the correct market place according to your country.
 
 
While for sure our bandwidth is more focus on Helios64, we are still supporting Helios4, and no plan to change that ;-)
For instance latest Armbian 20.05 Kagu still actively includes Helios4. Ok we will still need to put a post on our blog about that and link the image in our wiki :/
 
 
 

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.

Mainline kernel is of fairly decent quality in regard to most popular RK3399 boards. All critical components work fine and have really good support. But something, which makes such boards outstanding, still doesn't work in 5.*  It is normal for the situation when vendor's developers are locked inside of their private sandboxes (they call it SDK, LTS branch whatever, we call it simpler - "legacy") and do not really see the world is bigger outside  . However, I have good news for those who own RK3399 based SBCs with Fairchild FUSB302 controller responsible for type-c handling and power delivery protocol. This chip is widely popular, so there are some other users of its driver in the kernel and driver itself is very well elaborated (IMHO again). But it still misses many things that we, Rockchip+FUSB302 owners, really need. There is absolutely no need to write new drivers or wait when developers from Rockchip will do it (they won't). The driver deserves some extension and we will get both DisplayPort and properly working Type-C port (not statically fixed to USB3 host in the dtb, as many present maintainers do for their boards, but real DRD with role switching based on cable detection). I was working on this subject for two (or even three of last weeks, don't remember exactly anymore  ) and managed to fill this gap and get working DP on this "silently abandoned" port. Dual Role support for Type-C was in progress, but it can be solved too indeed. Right now, I have neither technical possibility nor motivation nor even time to continue anymore. The best what I can do is to recover what I've lost and handover my patches to some other volunteers who can/want to continue development (but even this needs a lot of time). My plan A was to deliver those features to my lovely Armbian community, and then try pushing it upstream.

A RaspberryPi and any board that is supported by Armbian cannot be compared really.
At RaspberryPi a lot of people working with just a few boards while at Armbian just a few people working literally on hundreds of boards which not even share the same sources. You see while at their place they have plenty of time to tweak every aspect Armbian simply cannot do that due to lack of ressources.

You dont have a Raspberry Pi 4 with armbian These are Rockchip64 SBCs  
because there is no armbian for the Raspberry Pi

I know most of you probably don't want to hear any more about this chip, but I recently fixed quite a few long standing issues.
It's not perfect yet, but it improves scanning/reliable reconnect, incoming frames missed in powersave, ping times, and rate selection.
Here's the patch set: https://github.com/fifteenhex/xradio/pull/12
Edit: rebased from karabek: https://github.com/dbeinder/xradio/commits/karabek_rebase
And some important comments about powersave: https://github.com/fifteenhex/xradio/pull/11#issuecomment-616226880
In short, relative to the current version, with powersave on, idle consumption is lower by 200mW, but with powersave off, it is 300mW higher
- so that should be a consideration if you want to integrate this into Armbian builds for tiny boards like OPZero.

Of course a 65MBit chip will never be fast, but I'd say it is pretty usable as an IoT node now. This hasn't seen much testing,  so your comments are appreciated.

Picture of first power / serial board. This is the old design and I am awaiting for new one (just got DHL notification of incoming parcel) 
 
I expect that till end of August the prototype will be assembled and electrically tested. Then as promised I will publish design and manufacturing files.

Me ...

Currently you can keep up-to-date the distribution packages via regular apt-get update && apt-get upgrade but not the kernel, u-boot and loader.
When I will merge the fork into mainline armbian (which will happen very soon), you will get also kernel and loaders updates!
 

https://www.zabbix.com/rn/rn5.0.1
 
 

We will post some info this week (on our blog and by newsletter) on production progress and shipping estimate.
 
 
 
Well we have some track record of donations to Armbian, and actually we are part of the Armbian team as mvebu family maintainer until now, and you can expect us to be very active on the rockchip64/rk3399 family. So even though it's never enough, I think we are doing our share of contribution back ;-)
 
 

i may hope the temperature reading is wrong. 83 degrees Celsius wil melt your case i think.

I've used Zabbix professionally and at home to monitor servers, IoT, and IP devices. I've built scripts for the server and client to automate the install process including moving the MySQL database, so you can locate it to a NFS mount instead of serving the database from the slower SD card. The deb packages do not work for ARM, so you have to build it from source using my scripts.
 
Install Zabbix

Thanks for this. Using xrandr I was able to rotate the display, and then updated my xorg.conf to set it permanently.

Finally, my very own :-)

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.

OK, i'm prepaired with my 500GB HDD on a Cubietruck right now...