Jens Bauer

That's good news, this means it is likely only be the EspressoBin is 'affected'. I just double-checked that it's not a "local error" (eg. my own stuipidity), the boot environment variables on the EspressoBin download page does load boot.scr to ${scriptaddr} and Focal's boot.scr does load armbianEnv.txt to ${scriptaddr}. ... So I'll need to try and make an armbianEnv.txt, which is large enough to overwrite the memory where the boot-script is located. Unfortunately, I currently can't get my board to boot from /dev/sda12 correctly; It keeps loading 'version 237' (from /dev/sda11) where it's supposed to load 'version 245.x'. It's driving me nuts and I'll probably have to rewrite the boot-sequence in order to get it to boot Focal. That again would probably mean I might not succeed in making the test.

... Looks very similar to espressobin; I once had a setup using 'loadaddr' (not load_addr), where loadaddr was used for both loading boot.scr and armbianEnv.txt as well.

I just came across this line: -Is this correct ? scriptaddr is where the boot.scr is loaded, as far as I understand, it overwrites itself by loading armbianEnv.txt to the same address. So wouldn't it be better to load armbianEnv.txt to kernel_addr, initrd_addr or fdt_addr, since armbianEnv.txt is only used for a short time ? I have not tried making an armbianEnv.txt, which is larger than boot.scr, but it looks like it would stop the board from booting if it's just long enough to overwrite the 'env import' line.

After running Bionic for quite a while, I decided to move on to Focal. Focal's RESET (reboot command) seem to be very robust, it has not failed me at all. So I bet the problem no longer exists with Focal and would like to recommend upgrading.

Thank you for your advice, I'll take it with lots of appreciation! :) I'm currently in the process of restoring my server, so I'll have to wait a few days, but I will try with a fresh installation of the most recent image from the download page. Unfortunately I only have one ZXSP drive, so I can't test with several drives of this type - it could have been very useful to know if it really depends on this drive type. Just in case someone reading this should be tempted: I think it's a bad idea to use BLUE (desktop drives) for a server - RED are much more stable.

I just experienced this old problem with Focal: WD drives inaccessible starting with kernel 4.13 -As the topic is now closed, I'd like to add some information. My drive is a 2.5" 1TB WD10SPZX (WD BLUE). It was connected via a Startech.com port-multiplier. Normally I use only WD RED, but I had to move some large files, so I attached it temporarily. Here's stack-trace #1... Stack-trace #2: I tried reading a large tar-file several times from the drive, but Focal kept crashing. After that, I tried switching to a WD BLUE (Slim) I had some data on already, and the copy from the tar archive completed without crashing. Here's a list of 3 different types of drives (connected via the same port multiplier): The tar-archive I was reading from, is very large (around 300 GB) and the file I was reading was around 2.3GB. 2.3GB would be a negative number as a 32-bit integer, but I don't think there would be any problem regarding this. All the partitions I work with are BTRFS partitions, but this shouldn't matter, since the problem seems to be in the driver. Oh, I used dist-upgrade from Bionic to get to Focal. Please let me know if there's any further useful information I could supply.

Fairly understandable. Cortex-A73 is by design (eg. ARM) using lower power and produces lower heat than Cortex-A72. Cortex-A75 even lower power and quicker than Cortex-A73. -So it will likely pay to choose the latter implementation over the former, even if the price of the CPU is higher. For build-farms and quick data-processing, it's interesting having high-speed CPU cores and high speed network (this can be spread out on several GbE ports or just a single 10GbE port). 2GB or 4GB LPDDR4 would also be attractive for this kind of configuration. Native 6G SATA would be a huge advantage here as well. For storage (eg. NAS), one could likely go with the old Cortex-A7, native 6G SATA support and 1GB to 2GB RAM (still 4GB will be interesting when you're using RAID configurations a'la FreeNAS, where each 1TB storage space requires 1GB RAM). Again as many (independent, full speed) GbE ports will be attractive for this configuration. If the CPU you choose have PCIe, you can basically do anything you want; just please don't waste the PCIe on USB3. Adding PCIe switches would be interesting too. As I've mentioned earlier, it's not easy to find an affordable board that has both native 6G SATA, GbE network and PCIe. I picked the EspressoBIN due to the low price and that it "technically" would cover my needs, but I've had many problems with it for several years. It still has problems when I make software-reboots (sometimes hangs), so that's a board I will not recommend. Some boards also have problems with the RAM being affected by EMI due to bad board design. The EspressoBIN was an empty promise; it can't be used as a router/firewall unless you add an external USB3-to-Ethernet adapter. The speed on the 3 ports is limited to 1Gbit for all three [eg. they share 1Gbps!], so I fail to see why they even bothered making the board more expensive by adding the Topaz switch. (Perhaps so that other board designers, such as you, can learn from their mistakes?)

Please add native SATA to the list. :) -I think it would not hurt to change the x4 PCIe3 to a four x1 PCIe3 or even four x1 PCIe2. -That way you can easily add cheap SATA host controllers or GbE adapters (with four GbE connectors per card). The 8040 is expensive, but I'd rather purchase one working board with extreme specs than 3 or 4 almost-working boards. -So for me, it takes time to save up for the MacchiatoBIN, but it's definitely worth it; and I want two DoubleShot boards!

A while back, I noticed that Armbian was compatible with this Ugreen GbE adapter. As I purchase on eBay rather than Amazon, I found the above one plus this adapter, which has the same AX88179 chipset plus a built-in 3-port USB3-Hub. So I decided to try it and see if it worked with Armbian and report back here. (I'm using the EspressoBIN for this and Ubuntu Bionic 4.19.56). These are my results: Straight out-of-the-box, I can see it using LSUSB, but it does not plug-and-play-work. After struggling and attempting to get the network manager to do something about it, I added this line to /etc/udev/rules.d/70-persistent-net.rules: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0e:c6:a3:d0:c6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="usbnet0" It now shows up as usbnet0 when I type ... ip a networkctl -a networkctl status usbnet0 ... I've successfully been able to set its MAC-Address (just to confirm that I can make a /etc/systemd/network/10-usbnet0.network file: [Match] Name=usbnet0 [Network] #DHCP=ipv4 DHCP=no Address=10.0.1.5/8 Gateway=10.0.0.1 DNS=208.67.222.222,208.67.220.220,10.0.0.1 [Link] MACAddress=defa.cebe.ef08 However, If I type ... ip link | grep -A 1 'usbnet0' ... I get ... 7: usbnet0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 link/ether de:fa:ce:be:ef:08 brd ff:ff:ff:ff:ff:ff Notice "state DOWN" networkctl -a shows this line: 7 usbnet0 ether no-carrier configuring (which is a little more than when not having the udev rule) nmcli device shows this line: usbnet0 ethernet unavailable -- The command ... dmesg | egrep 'eth|usbnet0|ax88179|link.*ready' ... shows ... [ 0.000000] psci: probing for conduit method from DT. [ 4.281896] mvneta d0030000.ethernet eth0: Using device tree mac address de:fa:ce:fa:ca:de [ 17.785161] mvneta d0030000.ethernet eth0: configuring for fixed/rgmii-id link mode [ 17.785225] mvneta d0030000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 17.797420] device eth0 entered promiscuous mode [ 18.480286] ax88179_178a 3-1.1:1.0 eth1: register 'ax88179_178a' at usb-d0058000.usb-1.1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:0e:c6:a3:d0:c6 [ 18.480614] usbcore: registered new interface driver ax88179_178a [ 20.583008] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready [ 20.889613] ax88179_178a 3-1.1:1.0 usbnet0: renamed from eth1 [ 21.366583] IPv6: ADDRCONF(NETDEV_UP): usbnet0: link is not ready [ 21.369227] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 31.927910] IPv6: ADDRCONF(NETDEV_UP): usbnet0: link is not ready [ 146.550026] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready ... So as far as I can tell, it does not seem to work right out-of-the-box, and currently, I seem to have used up all my ideas on how it could be brought up. The USB3-hub seems to be detected. If I insert a USB2 SD/MMC card reader, the device shows up as /dev/sd?, so the USB3 hub seems to work just fine. The question is whether the USB3 hub might confuse the driver in Armbian, because as I understand it, the adapter without the USB3 hub work out-of-the-box (please confirm).

Mini-PCIe is good a thing, you've got this one right! -But the specs need to be better on a SBC today. RockPro64 is doing things the right way; they pack the SBC with good specs while keeping the price as low as they can, resulting in a board with great specs, for a slightly higher price than the average boards (but it'll pay for the end-user to get this board rather than the lower priced ones). My personal priority list: PCIe2.0 or PCIe3.0 (x4 or more if possible). CPU-native 6G SATA (at least one port, but 3 ports would be very attractive) Low power consumption. GbE or faster (2.5GbE, 5GbE or even 10GbE) Choice of 1GB, 2GB or 4GB LPDDR3 or LPDDR4. Cortex-A57 or Cortex-A72 (or higher). HDMI 2.0a output (or better). Most casual users would expect to be able to use a SBC to play back video in very good quality.

Sadly it's not affordable for me. I'll still have to wait at least 3 months until I can purchase one. -But as you might have read elsewhere, I do plan on getting a couple of MacchiatoBIN boards. Even if the CPU is 3 years old, it's still very capable, compared to those we get on other SBCs today. But for me, the hardware is just as important; high speed networking, lots of quick RAM, native SATA ports and PCIe 3.0 is something I very much need. The board is a robust high-quality board and I'd expect it to last longer than any of my current boards. I will need to get/create some electrical protection, as lightning is very frequent where I am located, in addition to the high > 260V spikes on the AC-net. (A CubieBoard2+PSU and a switch have already been fried recently, unfortunately I still have my server on the same fuse as the water heater and fridge and it'll have to stay there for a few more months).

I guess I'm lucky to have two 1GB models, because they're likely faster than both the 2GB and 4GB models. I wonder why they didn't equip the 4GB model with heatsinks or cooling fans, so that we could see the max. speed (which is kinda what it's about). Some of us live on the south pole, some of us live on the equator; running the same benchmark in different locations will give different results unless making some basic temperature control...

And that was exactly what I was missing! Now it seems my worst problem has passed. Thank you very much, @ebin-dev!

Sorry, I was sloppy when I wrote the comment. What I meant was to cut them "inside" the adapter -eg. between the plugs. Thus I bet it should be possible to keep for instance CC1 and then put a 5K1 pull-down resistor on CC2 "inside" the adapter and then not connect CC2 to male-plug (which would connect to the RPi4).

Yep. They have acknowledged it and said that they're fixing the problem for next revision which should be out in "less than two months" (they've probably already fixed the schematics and PCB-layout, but I guess actual production slow down things). As a workaround, wouldn't it be possible to disconnect CC1 or CC2 or both and then add the resistor inside an adapter-cable [USB-C female-to-male] ?