TRS-80

Gents, 
 
Finally got it Installed , I'm so happy !! 
 
Now I'll check whats working or not (not interested in WIFI in case of failure) .
 
I used Armbian_20.11_Rk322x-box_buster_current_5.9.10_minimal.img  ( I dont need Desktop for my purpose)
 
Thanks Very much @jock and @fabiobassa for your patience and guide .
 
Sincerely
 
 
 
 

As long as you understand the limitations that dante6913 mentioned, and as long as you are only expecting to use it for server work, and I would add one additional item that you should only be expecting to use wired ethernet (wifi/bluetooth support is very spotty).
I would recommend just trying the last build that supports amlogic cpus (The 5.9.0 October 14th 2020 build) and follow the instructions in the first post of this thread:
Try the various dtbs for s905x3, sm1 (or s905x2, g12a) and see if any of them work well enough for your needs.  I have a TX3x3 box which contains a s905x3 and I use the meson-sm1-sei610.dtb for that box. 
 
The one thing specific to the s905x3 that might be unclear from the instructions on that post is that you will need to copy the u-boot-s905x2-s922 file to u-boot.ext as there is no x3 specific version, but the x2 version should work (at least it does on my TX3x3 box).

Hi,
I'm still unable to build the module correctly. The ZFS kernel module is build for kernel '4.4.213-rockchip64' (the headers version name) but the kernel is '4.4.213-rk3399'.
 
spl: version magic '4.4.213-rockchip64 SMP mod_unload aarch64' should be '4.4.213-rk3399 SMP mod_unload aarch64'  
I'm not sure this can be fixed without editing kernel headers, either :
/usr/src/linux-headers-4.4.213-rockchip64/include/config/kernel.release /usr/src/linux-headers-4.4.213-rockchip64/include/generated/utsrelease.h  
 
@ShadowDance Are you using the "current" 5.9 kernel ? Maybe this has been fixed for this kernel ?
 
BTW as the procedure is a bit tiring to do by hand, I wrote some scripts to automate this (build module on Ubuntu, utils on Buster) : https://github.com/Salamandar/armbian_zfs_compiler/
 
MOD EDIT:  Above is third party script, as always, make sure you understand what is going on before running it on your system.
 
Having gotten that disclaimer out of the way, thanks for your contribution, @Salamandar!
 
I took the liberty of marking this as solution.  I also made note of the link to refer others to, later.
 
Cheers,
TRS-80

I will try to build an image from trunk this evening and will give feedback on if that's working

After my last post I noticed the cute little tag 'Donator' was missing from my avatar so I went to re-subscribe and it shows conflicting info - if I roll over the blue badge top right it shows 'Subscription active' but in red in the middle of the box it states 'Subscription expired' and there is no where to renew it. Nothing clickable or obvious ...
 
I had donated to the server fund, did that mess up the auto? I noticed there is a recent charge so I assumed it is still working?
 
BTW, I think there should be an intermediate step between individual and corporate ... 5 Euros is nothing but 50 is more than I can do monthly.  Can you add a 10 Euros / mo?

We've added some enhancements to our mirror redirect tool the allow you to choose a region.   
 
UPDATE: See Friendlier Documentation Here

The following regions are configured:
NA - North America
EU - Europe
AS - Asia (currently only china)
 
to use update the url in /etc/apt/sources.list.d/armbian.list from apt.armbian.com to apt.armbian.com/region/REGIONCODE
 
ex:
 
# cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com/region/NA focal main focal-utils focal-desktop  
If you'd like to choose a specifc mirror you can query https://apt.armbian.com/mirrors and find a mirror

Armbian is based on open source software which is IMO the only warranty for our bright future and where its worth investing our precious time into. Everything else (Android, closed 3D drivers, Rpi, ... ) is fully dependent on corporations who owns closed libraries, licences, patents and which can and do decide how and when "open source software" will work or stop working.

Most if not all Androids are running private Linux forks interacting with lots of closed libraries for this and that - those libraries are usually locked to one kernel and can't be reused elsewhere. You can't upgrade anything. FOSS - on the other side - has to reverse engineer those libraries which interact with hardware or write them from scratch. Running pure and true open source Linux is a rare luxury. Especially in ARM world. Running it with open 3D drivers and open video accelerating routines is expensive / luxury ... but we are getting there.

I sloved!

I have a need for a low-cost machine for my daughter. I could buy a Raspberry pi and run Ubuntu on it, but
I have a few Amlogic boards at hand, and for the most part they work perfectly with Armbian (OK I know
they are not a supported board, and I don't run an official build).
 
My concern, though, is that lack of hardware support (audio, video decoding) which makes low-profile
hardware quite sluggish to use in the daily life.
 
My point is that I am tired of seeing perfectly usable (in theory) electronic products to to landfill (and create
an environmental disaster) just because software is falling short. Not even software in fact, but rather the
configuration of it. This is very frustrating because everything I'm talking about is supposed to be mainlined
and I believe I'm not attempting something unreasonable.
 
I need to learn more about those subjects, and reading this forum helps, but there are hundreds of messages
out there, most of them obsolete. So I don't know who to turn to, if you know a good place, please let me
know. The user that goes by the name of Balbes in this forum has done a fantastic job of putting out new
images as releases appear in the Linux tree, and elsewhere. I would like to sincerely thank that person. I
wish I has a tenth of their knowledge.
 
I have seen many related discussions in the LibreElec forum, but then my intention is not to run kodi. I am
not aware of any Amlogic-specific mailing list.
 
This post will quite likely be seen as a troll,  which it isn't, really, and brutally closed,  but at least it gives
me an opportunity to speak my mind.
 
Anyone knows a good place to start ?

Your  question is clearly sincere.  Thank you for being thoughtful in your post.
 
I recommend reading the sunxi wiki from head to toe.   Even if you're not interested in allwinner they do a good job of covering a lot of the theory.
 
https://linux-sunxi.org/Main_Page

I have been having some long running, on and off discussion with @lanefu in IRC (and elsewhere), because I know this is his area of expertise.  However he is busy, and I can appreciate he might not want to spend his free time talking about stuff he gets paid to do M-F. 
 
Then I also realized, certainly I am not the only one interested in Armbian in order to be doing such things.  So I thought I would make a thread about this, instead, to open the discussion to a larger group people here in the broader community.
 
I have my own thoughts, concerns, things I want to do, and have already done, but I thought I would make a more general thread where like minded people can discuss their experiences, what has worked (or not), what services you might be running (or would like to), etc.
 
I guess I will begin by saying I have been running some services for family and friends, first on a Cubietruck since maybe 2017 (or earlier?) and then later on some ODROID-XU4 in addition.  I run XMPP server (Prosody) which has been very hassle free "just works" as well as some experiments into Home Automation and other things which have had some, well let's just say mixed results. 
 
Currently my interest is in containers and like technologies, but I am very new to it.  I been reading a lot, but there is so much to know and I can't help but feel I am a bit late to the game.  That's by design though, as I don't like being (too) early of a technology adopter, generally speaking.  Well, certainly not with such "hyped" technologies like containers, anyway.
 
In fact I thought it was a bunch of baloney and hype for a long time, but even cranky old cynic like me now sees some advantages of abstracting things, changing servers/services from "pets" to "cattle" if you will, for reproducibility, redundancy, and other reasons.
 
Anyway, I am prone to walls of text of idiotic ramblings, so I will stop here and give some others a chance.    Hope everyone is enjoying their holiday weekend so far. 

I will try my best, but "time is the missing ingredient" as usual ...
(I'm currently chasing why SPI0 doesn't work properly on OPiOne+ while it was with few earlier kernel versions)

Looks nice, but do we need another plattform / bugtracker? We already have forum, github issues, github project / teams, jira.  Although nobody seems to use the github project/teams stuff anymore.

Debian was always known to be rock-solid.
Even their testing branch is usually working very well so feel free to give Bullseye a try. Or as workaround for you simply consider building transmission from source.

sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  

No, I didn't know about that. If I had had no idea what to do and searched for a solution I might have stumbled across it, but I fixed this without searching on the internet.

I was still seeing the issue on Armbian 20.11 Buster (LK 5.9) and it actually seemed worse (even with the 3Gbps limit). So, considering my suspicion of power issue (the push from @TheLinuxBug helped too ), I took the plunge and got a bit creative with my testing. 
 
Here's the TL;DR:
Stock power/harness has the issue even with only one drive connected Stock power/harness has the issue with UPS disconnected Stock harness has the issue when only powering via UPS battery (no PSU), this triggered the issue without even reading from the disk (idle disk, it happened immediately after boot in initrd) Separate PSU for disk and different SATA cable (no harness) == no issue  
The 3 Gbps limit was removed for these tests and I picked the ata4 port because I knew it could reliably reproduce the issue soon after boot. I've attached dmesg's from cases 2-4 and I've annotated some of them.
 
I'm leaning towards power-issue here considering case 3 and 4. For reference these drives are rated 0.60A @ 5V and 0.45A @ 12V. I would've liked to test the harness power / harness SATA cable separately but that's unfortunately quite hard, and I didn't have any SATA extension cables (female/male) that would have allowed me to test the harness SATA cable separately from power.
 
In case someone finds it amusing, here's my testing rig (case 4):

Notable here is that I performed the 4th test 3 times. The first time I had the drive powered on before powering on the Helios64, but the link was set to 3 Gbps for some reason. I powered both down and powered first on Helios64, waited 2 seconds, then I powered on the drive, this way the link was set up as 6 Gbps and no issues when dd'ing. For good measure I repeated this a second time and still no issue.
 
@gprovost Is there anything else I could test? Or would the next step be to try a different harness, PSU, etc?
 
@aprayoga I have indeed juggled them around, but my issue is with all SATA ports, unlikely that all of them are loose. And thanks for attempting to reproduce, I'll still need to check if it happens with other drives too, but that's a task for another day.
2-dmesg-internal-harness-no-ups.txt 3-dmesg-no-psu-only-ups.txt 4-dmesg-external-psu-sata-cable.txt

@Flávio Lima
 Bom Dia Flavio,
yes the forum is in english please be so kind to use that language.

Despite of this I understand a bit portoguese so for your question and as far as I know rk322x board DO NOT HAVE 4 gb ram, almost at actual time
the maximum I have seen is 2 giga
Usually shishion 5G have 2 giga of ram
 

Technically no android tv boxes are supported.  The work in these tv box forums is all experimental and unsupported by the official armbian project.  The balbes150 fork of armbian that is often referred to as armbian tv has never claimed to work on s905x3 cpus.  And after the Oct 14th build no longer will work with any amlogic cpus at all.  
Having said that, I have a TX3 X3 box with an s905x3 cpu that is running armbian, so it isn't a lost cause.  But since each box is different, you may not be as lucky with your box.  There is a thread that discusses the s905x3 boxes as various people reported their successes and problems over time.
 
 
 
If you want to give it a try, you can get follow the instructions in the first post of the following thread, using the Oct 14th kernel 5.9.0 build.
 
 
 
 

@Flávio Lima,
 
Forum is in English.  Please use some online translation tool.

Thanks. I wasn't implying there was something wrong with the build process itself, but the module that was disabled in the config. Here is the PR https://github.com/armbian/build/pull/2381

Yay 24 hour delay is over. This is regarding the degraded performance of the 2.5gbe on 5.8. I am unsure if my iperf results are aligning with what others are seeing. Given that tx offload is definitely off, I assume so.
 
Formulated context and question:
I have just put my helios64 together. I am seeing degraded performance of the 2.5gbe interface as warned.
The notes I saw everywhere were "disable tx checksum offload".
How do I check if tx offloading is on or off?
 

I tested with ethtool, and yes it is off.
❯ sudo ethtool -k eth1 | grep tx-checksum tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed]  
I assume I have nothing else to do but wait for patches to improve the degraded performance at this point?
 
Thanks for your patience and your answers!

@SymbiosisSystems I take it you have a set of 0.8.5 modules built? They work fine with the 0.8.4 zfsutils-linux package, but it requires the zfs-dkms package which will fail to build. We can work around this by installing a dummy package that provides zfs-dkms so that we then can go ahead and install zfsutils-linux / zfs-zed / etc. from backports.
 
Here's how you can create a dummy package:
apt-get install --yes equivs mkdir zfs-dkms-dummy; cd $_ cat <<EOF >zfs-dkms Section: misc Priority: optional Standards-Version: 3.9.2 Package: zfs-dkms-dummy Version: 0.8.4 Maintainer: Me <me@localhost> Provides: zfs-dkms Architecture: all Description: Dummy zfs-dkms package for when using built kmod EOF equivs-build zfs-dkms dpkg -i zfs-dkms-dummy_0.8.4_all.deb  
After this, you can go ahead and install (if not already installed) the 0.8.5 modules (kmod-zfs-5.*-rockchip64_0.8.5-1_arm64.deb) and zfsutils-linux.

Ok, I bought better SD card and now everything works great. Tank you!

With just a few local test hacks, I was able to bring up kernel 5.10-rc1 on sunxi this morning (based on the new megous branch):
 
root@air's password: _ _ ____ _ _ _ | \ | | _ \(_) / \ (_)_ __ | \| | |_) | | / _ \ | | '__| | |\ | __/| | / ___ \| | | |_| \_|_| |_| /_/ \_\_|_| Welcome to Armbian 20.08.14 Buster with Linux 5.10.0-rc1-sunxi System load: 2% Up time: 11 min Memory usage: 14% of 491M IP: 172.24.18.151 CPU temp: 34°C Usage of /: 24% of 7.2G Last login: Tue Oct 27 07:20:02 2020 from 172.24.18.20 root@air:~# cat /proc/version Linux version 5.10.0-rc1-sunxi (root@355045fc2473) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #trunk SMP Tue Oct 27 14:13:23 UTC 2020 root@air:~# root@air:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.20 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.10 GHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 816 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:97.72%, 648 MHz:0.22%, 816 MHz:0.20%, 960 MHz:0.23%, 1.01 GHz:0.15%, 1.10 GHz:0.19%, 1.20 GHz:1.29% (679) root@air:~#  
I tested this on a spare NanoPi NEO Air board I had; I haven't tried an arm64 build yet.  dmesg is clean; cpufreq works,  overclocking works, wireless works, etc.  Our 5.9 kernel patchset applied almost completely without error (there are a few other changes needed such as the builddeb patches and fbcon reversion patch we did).
 
In any case I just wanted to let people know.  Given that 5.10 is confirmed to be the new LTS and 5.9 is the new primary -stable,  I'm wondering if 5.8's days are numbered (like what happened to 5.7).  I'm happy to put some work into bringing 5.10 into build if there is interest.