TRS-80

@NanoP,
 
Please do not spam multiple topics of same problem. I merged the two topics together. I also gave them a better title, after reading through both.
 
Back to your issue, I am not sure what else to try other than what has already been suggested.
 
An in-line physical switch? Very hacky. There is a low power Sonoff if you end up having to go this route (if nothing else works). Then at least you could remote control the disconnect and reconnect of the USB wire (you said it is in an out of the way location).
 
Have you tried maybe changing USB cables? I am running out of ideas...
 
Maybe someone else will come along who has a better idea.
 
If/when you figure it out, please remember to come back and share the solution.

So a bit of progress on the testing front
 
a tool for testing freshly installed images on SBCs Jenkins testing to build kernel based on PR I'd love help enhancing the the jenkins scripts to make more accurate decisions on what to test based on file changes... I have some logic that does an okay job right now

Im a devops consultant and fluent in Ansible so I think im Obligated in that regard. I can at least handle the plumbing hopefully others can implement the more granular testing once the framkework is in place.

Ok chaps, final design of serial mux board, plus zip file full of gerber files.


serial-mux.zip
 
BOM:

 
 
manufacture.pdf
 
Simple example how to control mux from bash (not verified, concept only
 
#!/bin/bash # pin allocation MOSI_PIN=353 #GPIO2 SCK_PIN=3 #GPIO3 EN_PIN=19 #GPIO4 function gpio-setup { for pin in $MOSI_PIN $SCK_PIN $EN_PIN; do [[ -d /sys/class/gpio/gpio$PIN ]] && echo $pin > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$PIN/direction done } function gpio-write_byte { for i in {1..8}; do // set data pin to high or low value BIT=0 (( $1 > 127 )) && BIT=1 echo "$BIT" > /sys/class/gpio/gpio$MOSI_PIN/value // set clock high echo "1" > /sys/class/gpio/gpio$SCK_PIN/value $1=$(( $1 << 1 )) // set clock low echo "0" > /sys/class/gpio/gpio$SCK_PIN/value done } # 16 bits: -- -- -- -- -- b3 b2 b1 p7 p6 p5 p4 p3 p2 p1 # px - power status on port x # bx - serial connected to port x function setup_mux { local high_byte=$(( $1 >> 8 )) local low_byte=$(( $1 & 255 )) gpio-setup gpio-write_byte(high_byte) gpio-write_byte(low_byte) # toogle EN bit to latch new value on 595s echo "1" > /sys/class/gpio/gpio$EN_PIN/value echo "0" > /sys/class/gpio/gpio$EN_PIN/value }  

OK, now that I have read through this whole thread, as well as the Announcement over at Helios (and comments over there) I have some further thoughts...
 
 
 
I guess you were so concerned about the price, you saw the need to point it out twice?
 
Sure, x86/amd64 are fine, if you like firmware level backdoors into your system. Personally, I don't and therefore have stopped purchasing recent Intel/AMD hardware for a number of years now.
 
And besides he said...
 
 
Which I thought was quite reasonable (and rare nowadays with how greedy most business people have seen to become) and also allowing for several different options and use-cases. Quite nice in fact IMO.
 
Hopefully we will end up with Nice Things (tm) instead of some proprietary firmware somewhere. From what I can tell there shouldn't be any (required?) video, bluetooth, Wi-Fi stuff here. Those are usually the problem areas, so I remain "cautiously optimistic."
 
ECC
 
For those others like me looking for ECC (for ZFS, or similar), some slight bad news:
the ECC version will be only 2GB (not 4GB) and will not be available immediately at release Apparently up until now there were none at all ECC SDRAM modules available on the market. After reading their Announcement (including comments) I learned they seem to be in the pipeline and getting close (but will miss release). So, hopefully Soon (tm). Also, the only modules that are even available at all are 8Gb (small "b" = bits) x 2 of them on board (see pics) = 2GB (big "B" = Bytes) RAM total). So that is what we will be able to get, for now.
 
They say they will think about upgrading later to larger capacity, as soon as bigger modules become available on the market.
 
I am already thinking I am not sure how patient I can remain, after waiting for something like this for literally years. I may buy first available ECC model of this board, and then later on, well... Maybe I will finally get around to modding our toaster oven into a uController managed reflow oven...
 
Still better than anything that has come thus far, and if you are not doing de-duplication, etc. or certain other features (talking ZFS here) you don't need a ton of RAM (and old guideline of 1GB/TB or whatever does not apply). I plan on doing straight mirrors anyway, with large disks, for lots of different reasons.

I must say I am very satisfied with Armbian. Using it as my primary OS now. Just the graphics acceleration is not perfect yet (Retroarch, PP Racer etc.), but it is really usable. Keep on good work!

There is also possibility of a remote controlled relay switch that you would plug the power supply in to.
 
Sonoff are popular for Wi-Fi based control, bu there are also the ISM bands (315/433Mhz, etc. depending on your country rules). I use the former for SBCs, this way if they get "stuck" somehow to where I cannot ssh in any more, I have that option which I can reach from other devices on the network to remotely turn them off and back on.
 
Sonoff are nice if you get ESPxx ones, there is a vibrant ecosystem of aftermarket firmware, you can add temperature and other sensors to them, etc... and only a few dollars each!

You should send patch for that to U-Boot so next person which tries to use USB on OrangePi Win don't need to do that work again.

I (partially ?) solved the USB issue, it's now working in u-boot, the four USB ports are working, keyboard works (i can stop autoboot and write everything i want), and when usb key is connected, it's recognized as storage device, so it's all good !
 
These are the changes I made to orangepi_win_defconfig, just added these two lines :
 
CONFIG_USB0_ID_DET="PH9" CONFIG_USB1_VBUS_PIN="PD7"  
I now have a problem with iPXE, it loads the menu (on my server), but i can't choose any of the options on the menu (don't know if it's iPXE related, (u-boot / efi) bug/misconfig, i'll try with a rpi pi 3), but i think that it is not armbian related at all, i'll stop bother you with any non-armbian stuff

Is it possible to put some short blurb there also like:
 
"Best way to gain attention of ALL Moderators (currently online and future) is to Flag the post (little Flag at bottom) instead of PM any Moderator(s) individually..."
 
...or similar...

I was having issues connecting to certain APs, the password was always wrong even though I knew for sure they were right. In the end it was due to network-manager's random mac address trickery. After disabling it I could connect just fine. Maybe the random mac should be turned off by default as it can interfere with certain APs?
 
A quick fix, create /etc/NetworkManager/conf.d/99-disable-wifi-random-mac.conf and add the following;
[connection] wifi.mac-address-randomization=1 [device] wifi.scan-rand-mac-address=no  

I wanted to copy the following quote here, for others similarly concerned about such things:
 
 
When I expressed my disappointment and asked them why not just go all the way to fully libre bootloader (since they were so close anyway), my comment was censored. Because they censor discussion, I have no way of knowing whether they object to my question, or maybe it was my link to try and educate others about What is Free Software and why is it so important for society. Perhaps @gprovost can shed some light?

OK, now that I have read through this whole thread, as well as the Announcement over at Helios (and comments over there) I have some further thoughts...
 
 
 
I guess you were so concerned about the price, you saw the need to point it out twice?
 
Sure, x86/amd64 are fine, if you like firmware level backdoors into your system. Personally, I don't and therefore have stopped purchasing recent Intel/AMD hardware for a number of years now.
 
And besides he said...
 
 
Which I thought was quite reasonable (and rare nowadays with how greedy most business people have seen to become) and also allowing for several different options and use-cases. Quite nice in fact IMO.
 
Hopefully we will end up with Nice Things (tm) instead of some proprietary firmware somewhere. From what I can tell there shouldn't be any (required?) video, bluetooth, Wi-Fi stuff here. Those are usually the problem areas, so I remain "cautiously optimistic."
 
ECC
 
For those others like me looking for ECC (for ZFS, or similar), some slight bad news:
the ECC version will be only 2GB (not 4GB) and will not be available immediately at release Apparently up until now there were none at all ECC SDRAM modules available on the market. After reading their Announcement (including comments) I learned they seem to be in the pipeline and getting close (but will miss release). So, hopefully Soon (tm). Also, the only modules that are even available at all are 8Gb (small "b" = bits) x 2 of them on board (see pics) = 2GB (big "B" = Bytes) RAM total). So that is what we will be able to get, for now.
 
They say they will think about upgrading later to larger capacity, as soon as bigger modules become available on the market.
 
I am already thinking I am not sure how patient I can remain, after waiting for something like this for literally years. I may buy first available ECC model of this board, and then later on, well... Maybe I will finally get around to modding our toaster oven into a uController managed reflow oven...
 
Still better than anything that has come thus far, and if you are not doing de-duplication, etc. or certain other features (talking ZFS here) you don't need a ton of RAM (and old guideline of 1GB/TB or whatever does not apply). I plan on doing straight mirrors anyway, with large disks, for lots of different reasons.

OrangePi Win default configuration in U-Boot has only half drivers enabled for ethernet. I fixed that recently with https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi/commit/2936eb2d550a642275113464fc9dcbb03357c049 It will be part of U-Boot v2020.04.

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.