TRS-80

@Darius
 
I'm not sure how much more I can tell you about it, but I can try and help you. Using the same server image (or headless? which ever you prefer) start the board and login. Once in, run the following command - sudo lsmod
 
My Renegade lsmod:
sudo lsmod Module Size Used by zram 24576 4 rk_vcodec 65536 0 uio_pdrv_genirq 16384 0 uio 20480 1 uio_pdrv_genirq ip_tables 24576 0 x_tables 28672 1 ip_tables autofs4 40960 2 That should present you with a list of all the loaded modules and "hopefully" something that is not on my list that looks audio related.
 
Once said module is found, we can then unload it and place it in a blacklist. 
 
Example:
sudo rmmod pesky_rk3328_codec
 
Now with it unloaded, let us add it to the blacklist.
sudo echo pesky_rk3328_codec > /etc/modprobe.d/blacklist.conf
 
For that to take full effect we will need to reboot, but before we do that lets tackle the Wifi.
 
As for your Wifi troubles, let us try running - sudo nmtui
That should present you with three options, one being "Activate a connection" and from there you should see your available Wifi. Make your selection, enter your passkey and connect.
 
If anyone else has some suggestions, thoughts or corrections. Please feel free to interject.

@SvenHz I made some progress on tracking down this issue with zfs 0.8 on the Helios4, more precisely James Robertson (@jsrlabs) identified and fixed the missing Thumb-2 instructions used by the Armbian kernel, see the discussion on the ZFS mailinglist.
 
I went ahead and opened a bug report (zfsonlinux/zfs#9957), and one of the zfs developers proposed a fix in this pull request: zfsonlinux/zfs#9967. However, the fix needs testing, so I thought to bring this up here in the hope that someone else will give this a shot as well.

I'm biased, I actually run a PC Engines distributor... (embeddor) 
 
All APU2/3/4 run the same quad 1Ghz AMD Jaguar CPU.  They have zero 'IME' or similar options and run coreboot open source bios.
 
These units can support SATA controllers on the mPCIe which means you can potentially put 13 SATA drives on or more if you get fancy.
 
These units absolutely smash an esspressobin.  They are not in the same league.  I've build a couple of hobby CEPH clusters on 2C4 units.
 
They have good intel nics (seems a strange mix of an AMD SoC and Intel nic but I'm not complaining)

Are you sure you're doing everything right? Not long ago I tested buster and 4.14 on HC1 and it was ok.

Until recently there was a problem with 5.y on HC. And as @Igor said, wait or make yourself.
Or just start with buster and 4.14 and for some time when 5.x will be stable for HC then you will change.

As for OMV and clouds, I don't know what exactly doesn't work for you. For omv use armbian-config. But remember that omv 5.x is still beta. I still use 4.x because of 5.x there are a lot of problems all the time so I prefer to wait until the end of the year. You can run the clouds in the docker ... If you prefer video help, watch "Techno Dad Life" has a lot of material about OMV and docker but on x86 basis so you will have to show some independence in adoption.

As for HC1, try this one https://dl.armbian.com/odroidxu4/Buster_legacy don't worry, let etcher take care of the partitions. It should work ... If it still doesn't work and somehow this is a problem with 20.y then maybe https://dl.armbian.com/odroidxu4/archive/Armbian_19.11.6_Odroidxu4_buster_legacy_4.14.161.7z
 
Or go into old age and just install stretch 19.x / 4.14.x for me on HC1 works 100%. If that doesn't work, then you either do something wrong or you have hardware problems.
https://dl.armbian.com/odroidxu4/archive/Armbian_19.11.6_Odroidxu4_stretch_legacy_4.14.161.7z
 
 

I agree with the previous posters. Any supported / recommended board will run stable with most features working if you use good PSU (not micro-usb), sd card (or even better root on emmc or sata) and is sufficiently cooled. I'd suggest you go for boards with good mainline linux support (ie. 4.19 or 5.4) because more hardware is supported & if something breaks there are possibly more people fixing it versus boards which only have some old vendor kernel.
 
Apart from that unfortunately it is like you said, not every feature works on every board. In my experience this is mainly due to hardware producers advertising (hardware) functions although there is no real software support for it. Or randomly changing hardware (see espressobin) which breaks existing software... I suggest thinking about stuff you really need and picking a board afterwards. (You probably don't need an "Eierlegendewollmilchsau").
 
Personal experience: I'm running a Router/NAS based on ClearfogPro with M.2 SSD for OS, 2x HDD for storage (with mPCIe-SATA bridge) for about  3 years now with no problems (apart from stuff which I broke be installing dev kernels and so on). 
 
So, I am sending in the Clearfog Army!
 

In my experience this is caused by the Alsa for SoC audio support > Codec Drivers: X Rockchip RK3328 Codec
When that is enabled in the kernel config, the sdcard will get read/write errors during boot and throw you into readonly mode.
As a temp solution you could try to blacklist the module or build ur own img and disable it in the kernel config.
 
This by the way, does not happen when using an eMMC and yes, I believe TonyMac32 is already on the case.

Update - Touch panel is now working :)
20200122_102315.mp4

sudo ethtool -s eth0 autoneg off I have some device on s905x3 with rt8211 and ethernet not worked. So i take meson-sm1-sei610-ethfix.dtb from previos post.
Use AML+RK+AW linux image. But still no ethernet. Only tihs code help, it took 2 days ))
Thanks, to balbes150 ! good work. 

I use PA20,  PIN37. 
 
overlays=w1-gpio usbhost0
param_w1_pin=PA20

I do know know which image you are using as the link mentioned by you doesn't open for me. There is an another thread where you can ask for help.
 
You can ask others which image has the WiFi driver for that chip. In addition to that, the main author , balbes is kind of more active there as compared to current thread ( It is kind of outdated one). So, he might help you.
Other than that, you can check dmesg or logs to see if there are some issues with loading of WiFi driver.

I started contributing a few dollars per month to help defray server costs. I might like to increase this amount to help out in purchasing hardware, etc. As I stated before, I have almost no time for anything, but happy to contribute few dollars here and there as luckily I am in a position to do so.
 
I couldn't help but wonder however, how much the PayPal fees and exchange rate were eating into my little contribution each month? And if it's significant, maybe we can figure out a better way to transfer funds. I have a strong dislike for middle men taking a cut anyway. Parasites.

@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.