TRS-80

I don't even own one of these, but I am fascinated by how you guys finally got it stable it sounds like?  After all these years.  And the fact that Kobol (our once partner) went out of business years ago (I just looked and we are about a month shy of 3 years now).
 
Such triumph of the human will (and this project!), it could almost warm an old cynics heart. 
 
EDIT:
 
I updated (removed) the "instability" comments about Helios64 in my NAS article: So, you want to run a file server (aka NAS)?
 

mind the voltage changes I am uneasy to push to main until I either get no more crashes for a long long time or the issue is nailed down to its cause.
I might revisit this choice.
I plan to have the emmc hs400 fix in Armbian and vanilla linux. Probably not for the august Armbian release but I expect for the next one.

So I don't know about everyone else, but for myself I've had my helios64 running on Armbian 22.02 with the 5.15.93-rockchip64 kernel for some time.
 
Mine is an on-lan ZFS replication target for my main NAS, i.e. overnight low power local part of my backup strategy.  I always knew it was not performing to it's full potential but it doesn't fall over.
 
The biggest challenge I had was getting OpenMediaVault 6 on it with the ZFS plugins from the extras repository.  The upgrades around those broke so often I ended up learning Ansible so I could script the steps I was doing by hand.
 
Also, because of the quirks and the "if it breaks, it's going to be painful" situation of it all, I stuck to running from the SD card, which I have an image of at a stable point on my main NAS.
 
Every once in a while I would try to move it all forwards to newer versions, when it doesn't go so well I flash the SD card from the image and start reading the forums, which is what brought me back here 😅

I don't even own one of these, but I am fascinated by how you guys finally got it stable it sounds like?  After all these years.  And the fact that Kobol (our once partner) went out of business years ago (I just looked and we are about a month shy of 3 years now).
 
Such triumph of the human will (and this project!), it could almost warm an old cynics heart. 
 
EDIT:
 
I updated (removed) the "instability" comments about Helios64 in my NAS article: So, you want to run a file server (aka NAS)?
 

This is custom hardware world. There are many models, some are similar, some different, some very different. Some vendors sets names with complete absence of any logic ... and there is little we can do about.
 
 
Orangepi Debian and Orangepi Ubuntu are Armbian fork. They generate those images with Armbian tools that were forked few years ago and where they removed all other vendors out. Instead of cooperating with us on the same code base of the build FW, they "maintain" their own. Also kernels are maintained by https://github.com/orangepi-xunlong/linux-orangepi/commits/orange-pi-5.10-rk35xx/ (one person) vs. Armbian + community maintained (10+ people) https://github.com/armbian/linux-rockchip/branches. We have ditched this very old (named legacy at Armbian) kernel 5.10 few months ago and we just released 3rd version of (named vendor at Armbian) kernel 6.1.y. Both, legacy and vendor are provided by Rockchip and are containing many non-standard solutions that cannot and will never be mainlined. Then there are mainline based kernels, named current and edge, which are derived from kernel.org but heavily patched to provide as good as possible functionality. This latter does not interest HW vendors much as its beyond their control.
 

You need to have a strong reason to run their software. It's purpose is to sell hardware.
 

Armbian bookworm current is what you want. Only problem here is that we (Armbian staff) don't have re$ources to spent on this device, so it will remain community supported. There is also a version of this board that is broken and will only cause additional expenses. And our time is too precious. 
 

Absolutely not. Forget about kernel 5.1.y Its dead end, nobody is maintaining it anymore.

The only solution for legacy images is to downgrade to cgroups v1 with kernel parameter 
 
You add this in armbianEnv.txt
 
extraargs=systemd.unified_cgroup_hierarchy=0  
 
To use cgroup v2, you need to have kernel 4.15 or later https://github.com/opencontainers/runc/blob/v1.0.0-rc95/docs/cgroup-v2.md#host-requirements.
 
Other requirements you might need to set iptables debian os
 
The docker installer uses iptables for nat. Unfortunately Debian uses nftables. You can convert the entries over to nftables or just setup Debian to use the legacy iptables. sudo update-alternatives --set iptables /usr/sbin/iptables-legacy sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy  
 
As for non booting zero2 images please check latest, builds are working fine for me at this point, although I will check, (limited time atm, also 'not sure about mirrors synching').

You may have noticed that Helios64 was moved to the supported section again about two weeks ago: thanks to @prahal who volunteers as a maintainer !
I think this should be appreciated i.e. by reacting to his last message two postings earlier.

With the latest update initramfs solved. USB C port , unfortunatelly still doesn't work.

Hello. I just tried the latest Armbian jammy for PineBook Pro and the kernel refuses to boot. I tried to replace the 6.6.31 kernel with 6.1.63 from older image and it works without problems.

I slowly convinced myself that I wanted a PineBook Pro, some time after the first production run.  But then COVID, parts shortages, etc. happened and they were not available again until about mid-2022.  But when they were, I decided to snap one up.
 
And since then I have not been able to get it to boot Armbian.  It came from the factory with Manjaro, which for me being a Debian guy, might as well be useless.  So the PBP sat around collecting dust.
 
Since then I have tried a few times to get it to work.  I read many forum posts, tried some things.  I won't document all that in detail.
 
In this post, I will continue from where I left off here.  However to summarize, that was about comparing DTB/DTS files to Kali, which supposedly works.  That may become useful later, but I don't think that's the main problem.
 
I think that the main problem is that this new batch came from the factory with no bootloader flashed to the included SPI flash chip.  This is a problem on PineBook Pro because the RK3399 has a kind of weird boot order: SPI, eMMC, SD card.  Therefore, if you just put in some SD card you flashed, it still boots from the factory Manjaro from the eMMC.  Whatever bootloader they are using also apparently will not recognize an otherwise working Armbian image on an SD card.
 
Now, because of the weird boot situation, there is supposed to be a switch to turn off eMMC.  However this did not work for me.  Which means one of 2 things:
 
The switch does not work.  I read at least one other person saying this.  Also on the new revision, it's in a slightly different place than the old revision (may be a clue, maybe not). I simply had a bad Armbian image (which I had burned to sd card) that would not boot for whatever reason.[0]  
But let's put that aside for a moment.  As I still think the main problem is the (empty) SPI.  And that will be the easiest/best path forward.
 
I confirmed the 'blank SPI' theory 2 different ways.  First, as mentioned in a follow-up to the linked post (4 paragraphs above):
 
As Martijn Braam states here:
 
Of course, I like to beat a horse until it's really dead be thorough in my investigations, so today I wasted a lot of time[1] verifying that this indeed was the case.  I did so by dd'ing the /dev/mtd0 block device into a file[2].  When I examined the file, it contained all FF, and also it is about 16 MiB in size.  To me this confirms that indeed, the SPI on the new batch comes from the factory empty.
 
So what is next?  I keep reading that the only people who had success first had to install something like tow-boot to the SPI.  That will be my next step.  But before I flashed anything to SPI, I wanted to see what really came from the factory (which I did above).
 
I will continue to document my progress whenever time allows for me to work on this.
 
[0] Once I got the bootloader situation sorted, I later used this same image (on the SD card) to boot and install Armbian, so I do not think this was the case.
 
[1] In the end the solution was simple.  But first I wasted a lot of time trying to get rkdeveloptool working in Manjaro on the PBP.  Only to realize it's intended to be used from a second machine to read the SPI flash via USB in maskrom mode.  Anyway, lesson learned.
 
[2] I tried to attach it but maybe it's too big.

After the better part of a year being unable to use this device, I am pleased to announce my first successful boot into Armbian.
 
   
 
 
I accomplished this by installing tow-boot to the SPI.
 
If you check their instructions for the PineBook Pro, it says to install some 'installer' version first to an SD card, and then boot that, and use it to install to the SPI chip (or other media).  I did not want to do that for a few reasons:
I don't understand why all the faffing about with an indirect installation method via SD card? I don't seem to be able to boot via SD card anyway. I am really not interested in removing all those $#%^# screws from the back case again, just so I can flip a switch, then put them all back (twice, maybe more).[0] So what I did was dig around a little more until I found this issue from last year where people were saying just to do the following, essentially:
 
dd if=Tow-boot.spi.bin of=/dev/mtd0  
So I downloaded latest release of tow-boot, which comes as an xz compressed tar archive.  After opening that up the usual way with:
 
tar -xf pine64-pinebookPro-2021.10-005.tar.xz  
Under the binaries folder I found the Tow-Boot.spi.bin file.  I copied that over to PBP and then executed the above mentioned 'dd' command (via sudo).
 
I powered off and then back on, I knew it was successful because I saw the Tow Boot logo.  So I powered off and then inserted SD card I had prepared a while back with Armbian on it.
 
And yet it still booted into Manjaro on the eMMC.  So once Manjaro finished booting, I powered back down, then back on, this time pressing <ESC> to bring up tow-boot's boot menu.  After selecting 'SD card' I was able to boot into Armbian image on the SD card, which did the normal expansion and first run setup (entering passwords, locale, etc.).
 
Now this is interesting, because I had tried to boot this very same SD card before, without any luck.  Even turning the (previously mentioned) 'eMMC switch' to both positions[0], I could never get it to work.  So maybe there is something to the 'switch is broken on the new batch' theory?
 
Anyway, I guess that's it, as I finally have Armbian running on here.  It's a minimal/CLI image, so I still have my work cut out for me getting this all set up, but hopefully I can just install my preferred desktop packages and we will see how it goes.  But that's another project for another day.
 
[0] Which involves removing quite a number of tiny little screws and removal of the entire back cover.  And then putting them all back.  In the meantime you can't really use the keyboard or anything, so you pretty much have to do the whole %&#@%# process every time.  After doing this a few times, it starts turning into a hassle.

When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.
It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 
 
This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.
 

I see this has been solved but maybe it is helpful for others if I share my experience of the last days....

- had Manjaro KDE first and then later Manjaro Gnome running on my PBP, wanted to change desktop due to bad performance with Gnome and somewhat weird booting behaviour

- ran into a lot, really lot of trouble with these U-Boot hassle (u-boot, idbloader, trust) and repeatedly not working, at last not even booting and needed Reset directly on the the board

- was so close to kick the PBP into the trash bin

- but then wanted to give Armbian a chance 

- downloaded the version for PBP, version current, with Cinnamon. Unpacked, flashed to a SD card (with dd, no etcher ..), inserted into PBP, start: success!! System on SD booted at first step, ran into initial config, set up wifi: amazing!

- after half an hour enjoying this rescue of my PBP, I wanted to try to flash onto the emmc...

- after quickly finding out, that - other than the armbian doc tells - it's not via "armbian-install" on the command line, but via "armbian-config" in the menu. Chose "System on eMMC, Boot from eMMC"option. Started, it worked through and

- voila! Booting and running from emmc on first shot!!

- So easy can life be! I am really happy and thankful to Armbian, I am an Armbian fan now    😀

Igor, yes, I think the issue is the 'how to communicate this better' problem.  I understand your situation and I appreciate all of your work.  Let me add my perspective and the motivation that lead me to ask my question.
 
In this thread we see that there is a desire to have a working Linux distro for the Opi Zero 3.  Armbian is a great starting point--plain Debian would work as well, but Armbian has some SBC specific customizations that make it more appropriate--so that's what people tend to use.  Someone pointed out there was a mostly working version available.  They and others have been working for months to try to improve it.  I think all of this is a simple distillation of facts and it's in dispute.
 
Where there seems to be some issue is motivations.  I don't know the person who made the original port--"leeboby" on github.  I don't know what their long term intention is.  Maybe they are interested in their port becoming official and taking over an official Armbian maintainer role.  Maybe it's just a 'fire and forget' effort they did for some reason.  I don't know.  But the people here would clearly like to move towards some kind of more official board support under the Armbian umbrella.
 
To that end, the question was asked if there could be a board specific sub-forum created for this clearly unsupported board so that conversations about an unsupported board wouldn't 1) pollute the general unsupported board forum 2) make it clear that it was unsupported (to manage peoples expectations) 3) make it easier for people to find information on the effort to get this board supported by Armbian.  Having a sub-forum would help provide a sense of community and help develop interest in the effort.  *with hope* a maintainer would be attracted to or developed by this community.  As you point out, this is a completely volunteer effort.  I see people in this thread (before the split) who are showing interest in doing volunteer work.  I though I reasonably could expect a community manager to encourage the development of a community--in this case by creating a sub-forum for the board under the unmaintained board/sun-xi forum.

So, the question I though was being asked is "can this effort find a space to work?"  What you heard was "support this board!"  Your reply was "we aren't going to support that board without a maintainer".  What I heard was "we have no interest in assisting in your effort to support this board".  So, let me ask a better question now that I hope we all have a better shared understanding of the context of the question.

Is there a place in these forums for efforts to create support for currently unsupported boards to work?  It would need to be such that it's very clear to anyone participating that *the board is not supported and might never be supported by Armbian and that it's simply a community effort to try to reach that goal*.  I hope that addresses your concerns with people trying to abuse Armbian for support of other peoples ports.

If the answer is no, that's fine, this is your forum and it's up to you to decide how you wish it to be used.  I simply wanted the proper question to be asked so that we all knew what was being asked.
 
I just hope there's a way to collect community base interest and effort and channel it into something that makes Armbian better.  Thank you for all of your work and specifically the time you've taken to address this question of mine.

Hi
 
I had bought a NanoPi R4S with the goal of installing IPfire.
Unfortunately that was too complicated for me https://wiki.ipfire.org/hardware/arm/friendlyelec/nanopi-r4s
 
I had now installed Armbian and NextCloud and I am very satisfied. In about 10 hours I had "my own cloud". Therefore a very warm and big thank you to the Armbian developers.
Only thanks to the Armbian, I can look over the Raspberry horizon.
 
I wish you a very pleasant week
Best regards

Yay! I have it working
 
But I'm not an expert in compiling so ymmv
Feel free to comment or point out any mistakes
 
# when libshaderc-dev is installed the build succeeds, but has a run-time failure
sudo apt remove \ libshaderc-dev  
# install compiling tools
sudo apt install \ autogen automake cmake libtool meson pkg-config  
# install development libraries
sudo apt install \ libalsaplayer-dev libaom-dev libarchive-dev libass-dev libavcodec-dev libavfilter-dev \ libcaca-dev libd3dadapter9-mesa-dev libegl1-mesa-dev libfdk-aac-dev libfontconfig-dev \ libfreetype-dev libfribidi-dev libharfbuzz-dev libjack-dev libjpeg-dev libmp3lame-dev \ libmujs-dev libopenal-dev libopus-dev libpipewire-0.3-dev libplacebo-dev libsdl2-dev \ libsixel-dev libsoxr-dev libunwind-dev libva-dev libvdpau-dev libvkd3d-dev libvorbis-dev \ libvpx-dev libx264-dev libx265-dev libxpresent-dev libxxhash-dev libzimg-dev  
# clone mpv build script repository
git clone https://github.com/mpv-player/mpv-build  
# configure ffmpeg options by creating a file called mpv-build/ffmpeg_options with content:
--enable-static
--disable-shared
--enable-gpl
--enable-libaom
--enable-libfdk-aac
--enable-libfribidi
--enable-libmp3lame
--enable-libopus
--enable-libsmbclient
--enable-libsoxr
--enable-libvorbis
--enable-libvpx
--enable-libx264
--enable-libx265
--enable-nonfree
--enable-version3  
# configure mpv options by creating a file called mpv-build/mpv_options with content:
-Dlibmpv=true  
# start building
cd mpv-build ./rebuild -j$(nproc)
# strip executable
cp -p mpv/build/mpv /tmp/mpv strip --strip-unneeded /tmp/mpv touch -r mpv/build/mpv /tmp/mpv  
# test mpv
/tmp/mpv smb://myserver/myshare/myfile.mkv  
Yay!
 

I could be wrong, but I would suspect that the armbian-config script should actually install it.  But maybe it's broken?
 
So, if anyone does figure it out, please do submit a patch!

That's not the problem, the problem is the extra workload in modifying (and then maintaining) whatever parts of Armbian to support the 2 different init systems (as c0rnelius already went into some detail about).
 
And we barely have the resources to do what we do already...
 
Having said that, if it is something you feel strongly enough about, have at it.  But as c0rnelius pointed out, you would probably have your work cut out for you.

Hi all.
I made a new video on how to build Armbian images.
These days you can use your ARM64 SBC to do this.

For Windows users there's WSL2 you can use. Here my video about that.

Greetings, NicoD

Personally I like Mean Well, they are decent brand who tend to deliver the advertised voltage (which is a whole another problem with no-name supplies, not just in SBC world but also PC and others) and last a good long while.  And pretty affordable, usually.
 
Lately I have even been switching to DIN rail mounted power supplies for my SBCs (and other devices, even monitors, as I had too many power bricks piling up around my desktop/workbench area).

I recommend looking at Snort and Zeek. Most IDSs are just a rip off of Snort especially the commercially available ones. Zeek is kinda a packet analyzer but I have seen cool things done with it to make and IDS.

There was a time, 45 years ago when I was carving code for an rca 1802 with nothing but the rca programmers manual and a hex editor in a cosmac super elf, when I would have been in hog heaven at the prospect of such an offer But now I'm 88 and have mechanical things in my heart to keep my diabetic ticker running & keeping me going.  So the info traded would likely be from you to me, which doesn't pay your net bills However, there one law no one can break, TANSTAAFL. And I don't do business with paypal since their delays in approving an ebay purchase 20 years ago cost the owner of the tv station I was at, playing consulting engineer ar the time, about $50,000  in lost revenue, Rig your donation page to take my mastercard and you will see a donation as soon as I discover I can use one of my cards to pay w/o having to move it thru paypal.
 
In the meantime Igor, take care and stay well.
Cheers, <gheskett@shentel.net>

Interesting that yours doesn't freeze up on Segmentation fault etc.
I also have a suspicion that the amount and kind of drives installed as this has an effect on power drawer and possibly integrity of the 12V and 5V rails.
Grounds for the suspicion:
Suggestion to raise VDD to 0.95V to improve stability as done with other Rockhip RK3399 boards Preventing the higher CPU frequencies makes it more stable. High CPU freqs are more demanding on power. The fact they shipped the unit with big electrolytic capacitors soldered to the end of wires on the Sata loom. Seems like a way to help smooth power rails without having to redesign the board. Various other hints here on the subject of VRMs, cpu governor settings, ramp time, latency etc in relation to the  RK3399. https://forum.odroid.com/viewtopic.php?t=30303
https://github.com/u-boot/u-boot/commit/f210cbc1f3d4f84baa595d83933369b4d6a529ea
https://github.com/u-boot/u-boot/commit/5a6d960b222203e60ab57e19b3eb7b41c24b564b
https://wiki.t-firefly.com/en/Firefly-RK3399/driver_pwm.html
http://patchwork.ozlabs.org/project/uboot/patch/20191128061433.1952869-2-anarsoul@gmail.com/
 
So, @mrjpaxton interested to know how many drives you have installed, and what type (5400, 7200, or SSD)?
Also a possibility is running fewer tasks on the unit means the CPU has less demand and the governor may by rarely, if at all, trying to switch into the higher problematic frequencies.
 
update: my unit still hasn't frozen again since last post with the 4000-14000 omdemand so things are looking pretty stable. so far so good anyway.
 
 
 
 
 
 

@mrjpaxtonI defintely bulit the unit corretly. As I said in the post, I had a %100 stable unit on OMV5 with the image listed in the wiki for years.
Paying attention to this forum though, it's clear stability issues have been long running for many users and from what I can gather, the root problem is to do with cpu and power management. Quite a complex subject, something that PC overclockers would know more about than me.
@snakekick thanks for chiming in too. Good info.
Collecting info as I find it, it does seem like preventing the CPU from hitting the high end is the best way to go (contrary to other posts here).
Still running on-demand 400-14000 now on @bunducafe's info, and it's more or less stable. As it's only happened once so far since changing to that setting, I can't even confirm it wasn't some other insult to the system
 

Although this is doable. It would be a fairly large undertaking.  Any services and custom services currently used, would need a sysvinit equivalent. Then there is the question, would this also need to be integrated into armbian-config?  Probably, yes. Would all features in armbian-config even be supported in Devuan? I seriously doubt it. Also depending on how debs specific to Armbian are currently put together and the depends they may or may not have, those would also need to be modified.
 
Plus it would need to be extensively tested. I have found some scripts I run that are linked to services sometimes need modification when using them on Devuan. 
 
For a lot of boards though, on a basic level. It could be done.