TRS-80

I am sorry I cannot help you with details, but I can wish you good luck, and perhaps give some helpful general advice, on embarking on (what I can gather?) may be the beginning of your hacking career.
 
Stick with it. Try and not get too frustrated, especially if you are learning some of this stuff for the first time. Try and remember to have fun along the way.
 
It can go very slow at first, it may seem you are spending all your time "yak shaving" instead of making progress, but remember, learning is progress, too...
 
Cheers!

Well done, Werner!
 
Official announcement here (with connection details, etc.):
 

So my takeaway after reading up a bit more. For CPU/IO loads, Khadas VIM3 is a beast and looks unparalleled today, but is quite expensive and includes an NPU which you may or may not need. VIM3L is a bit lower specced but can easily be extended to get PoE, which is nice. ODROID N2 comes close, but is physically large. NanoPi M4V2 looks to be the most reasonable option on the market today - if only it came in a 4GB RAM version...
 
I feel that each of these boards is so close but each is missing one single thing that ends up making it a significant compromise.
 
XU4 is quite low-specced compared to each of these, and similarly priced to the NanoPi M4.
 
FWIW, linuxgizmos just compiled a decently comprehensive spreadsheet that is pretty up to date: http://linuxgizmos.com/ringing-in-the-new-year-with-136-open-spec-linux-sbcs-under-200/
 
Also, @NicoD has a lot of good stuff on his youtube channel: https://www.youtube.com/watch?v=2Yu8Rj7o9lk
 
For now I think I will hold off any new purchases and fall back to NanoPi M4V2 in absence of new models or price drops in the coming couple of months.
 
 

blobs:
https://github.com/armbian/build/tree/master/packages/blobs/mt7623n
https://github.com/armbian/build/blob/909be0239d8f3a9d6e2dae9da94d18b65e350320/config/sources/families/meson-gxl.conf#L18-L27
ends then in: https://github.com/armbian/odroidc2-blobs
 
so we even already dealt with bootblobs we've no clue what they're doing.. especially meson-glx
 
still needs the blobs to chainload UEFI (https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3):
 
 
the only serious attempt to avoid this was done by christinaa (https://github.com/christinaa/rpi-open-firmware) but more or less dead since months/years. So no there's no change that the RPi relies on bootblobs to get up and running
 
Cause the bootloader (bootcode.bin) only understands FAT you also need some tweaks here and there in the buildscript.. But most of the needed features are there cause we support(ed?) having /boot on FAT. According to jamesh from the RPi forum their engineers don't see a reason that a bootloader should understand something like ext4 (I would have to search in my posts in their forum to get you a quote for that).. But safest bet for a more or less "sane" implementation would be bootcode chainloads u-boot and u-boot then properly loads a kernel sitting in a ext4 partition.
 
IMO that doesn't fit to the 3b+ at all.. Maybe partly to the 4. In most when not all parts a rk3399 based on will outperform even the RP4 and for sure the RPi3
 
what do you mean with ROCK? means RockPi? then there you go:https://www.seeedstudio.com/PoE-HAT-for-ROCK-Pi-4-p-4143.html currently out of stock but allnet has it:
https://shop.allnetchina.cn/products/rock-pi-4b-poe-hat
 
I guess something like this will do the trick: https://www.aliexpress.com/item/33057941535.html?spm=a2g0o.productlist.0.0.38d222ebEfaAc9&algo_pvid=ebc883c9-19fd-4f58-ae77-add76220ba26&algo_expid=ebc883c9-19fd-4f58-ae77-add76220ba26-3&btsid=1071dcd7-b020-4d15-ab51-f383395eff93&ws_ab_test=searchweb0_0,searchweb201602_9,searchweb201603_53
obviously untested I don't deal with POE atm. Just make sure that you don't run into:
RK3399 tends to be power-hungry..
 
but back to topic:
have a sane implementation dealing with the bootstuff when possible don't add additional kernel sources (means build your kernel on top of mainline) Make sure that basic functionality even when you're not interested in works (e.g. USB/HDMI/UART or it's clearly that it doesn't work - well UART must work otherwise it's a pain to debug)  

Greetings everyone,
 
A couple years ago, I did my research and followed the recommendation here and on linux-sunxi to purchase a Cubietruck and have had excellent results.
 
I use my small low power GNU/Linux sever for all manner of things including self hosted "cloud" (contact, calendar, file synchronization), XMPP messaging server, media server, etc...  It has been such a success in fact that we are putting more and more of our valuable personal files on there like pictures, etc. and that has me thinking more and more about reliability, backup, etc...
 
I became very interested in ZFS but my understanding is that it requires 64-bit, but the state of 64-bit ARM devices seems... well, not quite ready for prime time just yet?
 
I have spoken to some friends and family about my self-hosted solution, and a few of them are interested now in doing something similar. So now I am thinking along the lines of purchasing a second (and/or third...) Cubietruck and putting together a sort of distributed cluster of little servers at different locations where we each back up one another's data.
 
So I guess my question is, should I pull the trigger now and purchase additional Cubietruck(s), or just sit tight and wait a little longer until 64-bit ARM matures? Or perhaps there is some other option I am not aware of (hardware recommendation)?
 
My primary concerns are privacy, including keeping my own data on devices I physically control or have access to. Also the whole state of affairs with blob bootloaders is very troubling to me, but it has been difficult for me to find specific info on this, at least with regard to specific ARM based hardware. Maybe I am not looking in the right place(s)? Any pointers about where to find such information would also be greatly appreciated.
 
To give you an idea of where I am coming from, I spent years and hundreds of dollars acquiring a number of KGPE-D16 motherboards and related hardware (ECC RAM, etc.) to run Libreboot and ZFS, only to measure the power consumption and realize that at hundreds of watts it was totally unfit for the purpose of a 24/7/365 server. I just don't want to make any more really bad mistakes like that. I know there are some very knowledgeable people here, and I am hoping some of you can contribute to a discussion that would get me (and others who think similarly) looking in the right direction.
 
TRS-80
 
P.S. - I just want to thank everyone here who is doing such a fine job. The developers as well as those who help in answering questions in the forums, etc. I am very short on time these days and cannot help out in that way myself currently, however I did make a small monthly financial commitment in the form of a membership. It is not a lot but is the least I can do. I feel that those of you who spend your valuable time on development, support, etc. should not have to come out of pocket for server costs and other small expenditures. I know that I personally greatly appreciate your work, I'm sure others do as well, even if they don't say so as often as they should. Cheers!

There is also the issue that RPi has a locked down bootloader / RTOS / GPU blob running underneath the OS, which is totally unacceptable from a Freedom standpoint.
 
Debian (which Armbian is at least partially named after) to me (and I am sure many, many others) stands for some other things besides the technical bits of the package manager and software repository. Debian takes a strong political stance in favor of Free Software.
 
Now this is not something that Armbian (as far as I know) officially adopts. And in fact I think there are some other blobs in certain places that are required to get certain boards to run, etc. I am actually still trying to figure all of this out but in the meantime, just something I wanted to bring to your attention for consideration.

Somehow "request not receiving attention" got turned into "TRS-80 not receiving attention" which was not what I said. I do not need attention.
 
@Werner, I think you said something in IRC once ~ about certain aspects of Moderation only being for autistic people. I want you to know I got a nice grin out of that. I don't take offense, and I think I am probably on the spectrum somewhere. In fact, I think it makes me perfectly suited to the job of getting the forum in order.
 
But as it stands, this fuzziness and (to me) disorganization is driving me nuts... REEEEEEEEE 

Yeah, this is the main issue.

At FOSDEM 2020, in roughly a few days (at 2pm, Sunday 2nd of Feb, Brussels time), there will be a livestreamed explanation given of the “FOSDEM Video Box” HDMI capturing devices.  They use almost 60 of these ARM-based devices during the FOSDEM conference to capture both the video output of all presenters laptops, and the video and audio of the camera filming of the presenter. Serious video hackery accomplishes this. I would encourage anyone interested to check out the bio of Luc Verhaegen, one of the presenters.
 
Using these "Video Boxes", FOSDEM inexpensively streams 720p videos of all 800+ presentations! This is a small miracle, IMHO.
 
They use Olimex Lime 2 boards, because apparently they believe that the Allwinner A20 is easier to do their custom video stuff on.

Moved to P2P until we know that this is problem is hardware specific, or even related to Armbian for that matter.

I merged @balbes150 "Section for flood." topic with this one, as they are related.
 
 
I would argue the opposite is true. Maybe my arguments (see above) are more clear now since I merged the two posts.
 
 
Possibly so. Then the questions become:
Do we want to moderate or not? Do we want to try and get the forums in a more organized shape, to make it easier to find information, or not? I thought that the intent behind the original request for more Moderators was (quoting Igor here):
 
 
At least for me, this is exactly what I signed up to do.
 
To be honest, I am starting to get a little frustrated at how such a simple (and to me, necessary) request is barely receiving any attention. My time is valuable, I cannot stay out of work forever, the bills do not stop. I have some savings and extra time on my hands right now and so I volunteered to help clean up the forums. I know everyone is busy and maybe during a release is not the best time, but this is the time I have. My window of opportunity of having this time is going to pass and then what? Nothing will have been changed, fixed, or improved... I have tried to be patient but perhaps I need to be more clear what constraints that I am working within.

I also think we are missing a couple sub-forums. I added to the topic here but so far no response.
 
Now that I am beginning to know my way around, I would like to sort some things out. But I don't want to put a lot of time/effort into that, and then we add couple sub-forums later, and I have to do all that work all over again. I personally am not interested in wasting my valuable time/energy on doing things more than once (especially when it is not necessary).
 
There are also a couple related questions:
Are we really going to enforce the policy that "General Linux / Debian / Ubuntu questions -> www.duckduckgo.com" ? Because if so, I think we will piss off a lot of people. And if we are not going to enforce that, IMO then we need a place to put these posts, to keep them separate from actually Supported things like Armbian scripts, etc. Hence my proposal to make separate sub-forum for that, under P2P to make it clear this is not for Dev support but community. And just to keep things organized.
 
Oh, I just noticed I did not actually add that to my post over there. But it is here on my "WIP" notes for proposed forum structure change. Which I will be happy to update, but so far there has been no discussion so I haven't bothered.
 
A similar / related question, from TV Boxes sub-forum:
 
What is/will policy be about discussing Android based boxes?
Anything goes (full discussion of Android alternatives OK)? OK only in comparison to Armbian? None allowed at all (only Armbian discussion)? I know people are busy, and @Igor has mentioned (and I see) that things work slow. But I have some time on my hands right now and could contribute a lot to cleaning up / organizing the forums. But not, IMO, until we slightly tweak the current forum structure by adding just a couple sub-forums. Not a major change, just a slight re-organization (please see my link posted above, no need to repeat stuff I already posted -- and probably I might even merge these two posts over there anyway).

Is it possible to create a separate section for non-core discussions ? For example, I would like to send topics similar to this one there.
 
 
 

Yeah, but my guess is it is not intended by the developers over there to work this way
 
https://gist.github.com/EvilOlaf/ee16e3325b702a95b264dfc65937a78d
 
The last command before it dies is debconf-apt-progress -- apt-get --yes --no-install-recommends install netcat idn2 sqlite3 dns-root-data lighttpd php-common php-cgi php-sqlite3
If I run it by hand it dies the same way.
THOUGH if I remove the debconf-apt-progress it runs fine....
 
I provided a bunch of log files to pihole and cews kind a confirmed the issue. Lets see if they can fix it.

I finally got ZFS installed on my Helios4 using Armbian 19.11.3 Buster with Linux 4.19.84, but I had to stick with ZFS version 0.7.12, as advise by @SvenHz in this post. Loading the ZFS 0.8 module would fail with the same error.
 
@Steven Keuchel  Thanks again for your input on the kernel/ZFS memory settings. I had a more detailed look at your settings and noticed that you set `zfs_arc_max=805306368` (i.e. to 768 MB), which corresponds to the maximum `vmalloc` you seem to use. Or were those ZFS settings with `CONFIG_VMSPLIT_2G` and you use in fact an even higher value for `vmalloc`? Which ZFS version did you use, 0.6 or 0.7?
 
As @qstaq stated, the default for `zfs_arc_max` is 50% of the available memory. There is however a pull request to increase this even further to 3/4 of all memory or all but 1GB, whichever is greater. This change is enabled due to the revised memory allocation for the ARC buffers in ZFS version 0.7.  In fact, this change makes me wonder if those settings for `vmalloc` and `zfs_arc_max` still make sense for ZFS >= 0.7. 
 
The fundamental issue with the extensive use of the virtual address space in ZFS was outlined rather well by one of the developers in this ZOL issue. This was addressed however in version 0.7 with the introduction of the ARC Buffer Data (ABD), as also mentioned in the ZFS 0.7 release notes.
 
It appears that the issues with the virtual address space are limited to ZFS versions 0.6 and older. Or is my understanding of this incorrect? Any advice or comment in this regard would be greatly appreciated.

A few of us have been experimenting with this the last week or so, seems to work well. But I wanted to bring this to the attention of all the rest of longer term Mods like @chwe @balbes150 @NicoD @TonyMac32 @JMCC (please tag any others I may have forgot) as well as site level Admin like @lanefu and of course @Igor.
 
As a new Mod I often feel like a Level 1 Tech Support. Or perhaps better stated, "triage." Which I figure is our purpose, to "take care of" as many low hanging fruit as possible (or at least sort to correct place, maybe adjust title, tag, ask OP for further info, etc.), in order to free up time/attention of Devs and more experienced users. I try to take on as much as I can, but there are simply things I am unsure about (and from private discussions, I know other new Mods feel same). As our knowledge grows over time, we will be able to take on more and more. But I think we can slightly better use the tools this software already provides to help with this (IMO, some times necessary) mentoring process. I realize you guys are busy (hence need for Mods in first place) however...
 
Give a man a fish, and he will eat for a day,
Teach a man to fish, and ...
 
So I request to the more experienced Mods and Admins, please take few moments here and there to help teach us newer guys (when we need help) how to fish...
 
But this post will also be for my fellow new Mods, as well ( @soerenderfor @Vanitarium @_r9 @jsfrederick , I went through Mod sign up thread already, but please tag any others I may have missed) so please, read on...
 
Newer Mod (or even regular user) can click on little Flag at bottom of any post:

 
And then enter some question what they need guidance about:
 

 
Now this will show up to all other Moderators and site level Admin as little triangle in upper right corner:
 

 
So far pretty simple, I am sure most of you are aware of this functionality already. Now this is what I propose to codify into some kind SOP:
 
If we still require attention / advice of someone "higher up" then we leave Status as "New Report" (Flag logo):
 

 
Once someone "higher up" replies, then they/we can change Status to "Under Review" (Triangle ! logo):
 

 
Where we leave it until person originally raising the flag either:
gets their answer, at which point they can Close the Report, requires further clarification, in which case they can change back to Flag to raise more attention  
I think this is a good way of fast, easy triage and sorting, because:
it does not pollute IRC or forum threads (and less airing of potentially "dirty laundry") relevant discussion is attached directly to the thread in question "higher experience level" (Mods, site level Admin) can immediately see filtered view of what might need their attention (Flag logo), without having to read all of forums, or even pay attention to Moderation discussions, where they are not needed. However at same time should they want, can also get quick overview of moderation advice being given by Mods to each other, and could add their 2 cents if disagree. "medium experience level" Mods can help mentor lower level, to extent they are able, already relieving some load off "higher level" people, while still asking some questions themselves "lower experience level" Mods (and even regular users for that matter, although unable to see discussion on the Mod side) can get their questions answered, receive mentoring from "medium and higher" level people, and thereby eventually progress upward Over time, this will also build a body of knowledge which new Mods can look through when they have time to get up to speed (similar to reviewing past Bans, etc.)  
Do note that this entire proposal is only for the meta of Moderation questions themselves, i.e.:
should this be moved to x sub-forum I am not sure this qualifies as violating rule # x etc.  
If you think this is a good idea, please say so here, and/or just start fulfilling one of the roles "low, medium, high" as outlined above, befitting your experience level.
 
I encourage any and all Mods to communicate with each other in this way, adding your $0.02 to whatever Mod discussion, where you feel it adds some value.
 
Feedback on this idea also welcomed, of course.

Effectively I should have blurred the domain info, I made the assumption it was one of those domains from anonymizer email portal
 
 
Yup happy to that and move on And be sure we appreciate to you seem to very interested by our board.
 
 
Maybe @aprayoga can bring a bit of clarification here about the the chance that the work that has been done U-boot mainline could translate into not having to use RKBIN preloader one day.
 
 
Yeah the main reason we added the M.2 SSD slot was to give more option in term of enclosure design for people having specific use case to address. The other reason is that the M.2 Slot has also USB 2.0 interface and can be used to installed NPU extension board.

I can live with a bluetooth adapter inside. It would be stupid if the USB stick had to be inside otherwise. 
I would say that the issue is considered complete.
 
Thanks @Igor for the care!

The latest libgl1-mesa-dri upgrade brought with it panfrost to the desktop
 

Because this "one person" is responsible for the performance of a special version of Armbian for TV boxes and knows for sure that this shitty model will not work properly with Armbian, and will require those who buy it for use with Armbian to spend more money (obviously more than if they bought another model with a normal configuration of iron), in order to somehow make this stuff work. And buyers will regularly distract and spend forum resources to ask the same questions about why this shit doesn't work. Neither any justification, they say that this model can be used for other systems, not relevant here, want to discuss the launch of the other systems on this shit, use the appropriate forums. Unlike you, other users regularly ask questions on different TV boxes about the possibility of using them, and no one behaves so aggressively, trying to impose a discussion of this shit on everyone. They get an answer (by the way, not only from me, but also from other experienced users), about the suitability of using a particular equipment, and then decide what to do, without hysterics and screams on the forum, if they were told that the selected device is not recommended to take.

Small progress update -
 fresh photo.
 
 

Hi Igor,
 
thanks for your fast reply. Today I had the time to check it and indeed, after prepraring the emmc card with nand-sata-install script now everything works fine :-)
 
Thanks again
  garysn

Hi there, 
after days of researching I have finally found what caused the issue. 
Checked if STUN is working with my NAT - works fine  (stunclient --mode=full stun.stunprotocol.org reports success).
Checked if arm7 version of webrtc library is installed ("export TARGET_ARCH=arm" before npm install).
Compared the debug output of webtorrent (DEBUG=bittorrent-tracker:client webtorrent) of working and non-working setups. Bingo! WebSocketTracker output was missing on malfunctioning system. After analyzing the source code, realized that the only reason why it may happen is different behavior of API functions. Yes, outdated Node.js.
Solution is upgrade to Node.js 10.0+ as shown here:
https://joshtronic.com/2018/05/08/how-to-install-nodejs-10-on-ubuntu-1804-lts/

After upgrade i can seed files with streaming webtorrent, works as a charm. 
 

I pushed a template for the NanoPi NEO (2/Air/Core/Plus2) onto my github:
 
https://github.com/Tonymac32/kicad-templates
 
If you want to make add-ons, that's fully labelled and the header positions are as correct as I could get them without official reference.  I have made a few boards with it, so can vouch that it will assemble.  I'll add more as I have time and money to do so, since I don't want to push any that aren't verified in some manner.

Both M.2 and 2.5" SSD models push the same 560/530MB/s regardless of the connection (R/W on a WD Blue 1TB 3D NAND for example),  pretty much all of the SATAIII M.2 cards max out at 560/530MB (as do the SATAIII drives).
 
ARC cache is in memory and can be extended to L2ARC cache on a SSD as a read cache, very curious to see how this performs on the Helios64 and if the 4GB of RAM is suitable. I pre-ordered BTW, so I guess I'm going to find out!
 
Maybe a little ambitious, but my goal is an Armbian\OMV\ZFS\Docker system.