Espressobin support development efforts

lanefu · April 21, 2017

I'm sooooo close to sharing a WIP for building armbiain for espressobin , but I'm having trouble getting armbian builder to use the file name for the kernel package deb.

 │ dpkg-deb: building package 'linux-headers-4.4.8-mvebu64' in '../linux-headers-4.4.8-mvebu64_5.27_arm64.deb'.                                                             │  
  │ dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.27_arm64.deb'.                                                                                       │  
  │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64' in '../linux-image-4.4.8-mvebu64_5.27_arm64.deb'.                                                                 │  
  │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64-dbg' in '../linux-image-4.4.8-mvebu64-dbg_5.27_arm64.deb'.                                                         │  
  │ dpkg-genchanges: binary-only upload (no source code included)                                                                                                            │  
  └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘  
    


dpkg-deb: error: failed to read archive '/root/output/debs/linux-image-mvebu64_5.27_arm64.deb': No such file or directory

What's the cleanest way to have the resulting deb and armbianbuilder line up?

Stuff I've done:

made esspressobin.wip board config
Made mvebu64 sources config
Made mvebu64 Kernel config
Made kernel patch to elminate the localversion file
assured VERSION_AUTO is disabled in kernel config

Files n stuff

esspressobin.wip

Spoiler

# Marvell Armada 37x 1xmPCIe 2xGBE

BOARD_NAME="espressobin"

LINUXFAMILY="mvebu64"

BOOTCONFIG="mvebu_espressobin-88f3720_defconfig"

#BOOTCONFIG="mvebu_armada-37xx"

MODULES="mv_cesa"

MODULES_NEXT="mv_cesa"

CLI_TARGET="jessie,xenial:default,next"

KERNEL_TARGET="default,next"

BUILD_DESKTOP="no"

#

BOARDRATING=""

CHIP="http://docs.armbian.com/Hardware_Other/#marvel-armada-espressobin"

REVIEW="http://forum.armbian.com/index.php/topic/TBD/"

HARDWARE="http://wiki.espressobin.net/tiki-index.php?page=About+ESPRESSObin"

FORUMS="http://forum.armbian.com/index.php/forum/11-other-boards/"

mvebu64.conf

Spoiler

ARCH=arm64

KERNEL_IMAGE_TYPE=Image

HAS_UUID_SUPPORT=yes

#OFFSET=2

BOOTSCRIPT="boot-marvell.cmd:boot.cmd"

BOOTSOURCE=$MAINLINE_UBOOT_SOURCE

BOOTDIR=$MAINLINE_UBOOT_DIR

BOOTBRANCH=tag:v2017.05-rc1

BOOTENV_FILE='clearfog-default.txt'

HAS_UUID_SUPPORT=yes

case $BRANCH in

default)

KERNELSOURCE='https://github.com/MarvellEmbeddedProcessors/linux-marvell.git'

KERNELBRANCH='branch:linux-4.4.8-armada-17.02-espressobin'

KERNELDIR='linux-marvell'

DEB_BRANCH=4.4.8

# CHOSEN_KERNEL=linux-image-linux-4.4.8-armada-17.02-${LINUXFAMILY}

;;

next)

KERNELSOURCE=$MAINLINE_KERNEL_SOURCE

KERNELBRANCH=$MAINLINE_KERNEL_BRANCH

KERNELDIR=$MAINLINE_KERNEL_DIR

KERNEL_ALT_GCC='> 6.1'

;;

esac

## can probaly go slower

CPUMIN=800000

CPUMAX=1200000

GOVERNOR=ondemand

write_uboot_platform()

{

# dd if=$1/u-boot.mmc of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1

echo "hey"

}

family_tweaks()

{

chroot $CACHEDIR/$SDCARD /bin/bash -c "apt-get -y -qq remove --auto-remove lirc linux-sound-base alsa-base alsa-utils bluez>/dev/null 2>&1"

}

Edited April 23, 2017 by zador.blood.stained
Renamed to reflect the contents

zador.blood.stained · April 21, 2017

Did you add a packaging patch (based on any existing ones for the close enough kernel version)?

lanefu · April 21, 2017

I don't think so..... telll me more please

tkaiser · April 21, 2017

You need something like this https://github.com/igorpecovnik/lib/blob/master/patch/kernel/mvebu-default/packaging-4.x-with-postinstall-scripts.patch

zador.blood.stained · April 21, 2017

You need to add a kernel patch i.e. based on this: https://github.com/igorpecovnik/lib/blob/master/patch/kernel/mvebu-default/packaging-4.x-with-postinstall-scripts.patch

You may need to adjust it i.e. to use Image instead of zImage for the kernel file name. Also please keep in mind that you'll have to add a new boot script since boot-marvell.cmd is for 32-bit systems, and arm64 most likeky will use booti instead of ~~bootm~~ bootz and Image instead of zImage.

lanefu · April 21, 2017

thanks Zador, Tkaiser.. that's a big help..... Will probably take me a bit to digest what the patches are doing, but that's part of the fun.

lanefu · April 22, 2017

sweet the patch for mvebu you all linked to worked fine on mvebu64.... Image FS wasn't showing as valid. so gonna clean image caches etc.

I'm building u-boot,but it's really a placebo for now. the espressobin comes with it's own u-boot fork installed on NOR

Edited April 22, 2017 by lanefu
sounding less stupid

lanefu · April 22, 2017

making progress... I can get the board's u-boot to boot armbian now.. I have some quirk where i'm not sure the root password is getting set during install_common().. when I try to login from the console it doesn't prompt for a password when i try to login as root.

...but i think it's my image.. gonna switch to a better build host in AWS instead of my Docker on top of NFS host

lanefu · April 23, 2017

Aha! the console wasn't in /etc/securetty (/dev/ttyMV0)

victory!

I'll kick off a WIP thread soon--once I get things a little more dialed in...

armbian monitor seemed to work out of the box too

lanefu · April 23, 2017

omg okay this thing is cool.. surprise you have to call the ethernet devices by WAN, and LAN then it works.. Quick iperf test to a C2D dell optiplex looks solid

Also.. it also see's my add-on mini-PCI sata card. AKA I'll have 3 real sata ports for doing raid5

Spoiler

root@espressobin:/sys/devices/platform/dsa@0/net# iperf3 -c garagebox -p 9000

Connecting to host garagebox, port 9000

[ 4] local 192.168.3.104 port 46830 connected to 192.168.3.176 port 9000

[ ID] Interval Transfer Bandwidth Retr Cwnd

[ 4] 0.00-1.00 sec 113 MBytes 946 Mbits/sec 0 409 KBytes

[ 4] 1.00-2.00 sec 112 MBytes 936 Mbits/sec 0 409 KBytes

[ 4] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 409 KBytes

[ 4] 3.00-4.00 sec 112 MBytes 940 Mbits/sec 0 409 KBytes

[ 4] 4.00-5.00 sec 111 MBytes 931 Mbits/sec 0 431 KBytes

[ 4] 5.00-6.00 sec 112 MBytes 936 Mbits/sec 0 431 KBytes

[ 4] 6.00-7.00 sec 112 MBytes 938 Mbits/sec 0 431 KBytes

[ 4] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 0 431 KBytes

[ 4] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 431 KBytes

[ 4] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 431 KBytes

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 0 sender

[ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec receiver

iperf Done.

root@espressobin:/sys/devices/platform/dsa@0/net# iperf3 -c garagebox -p 9000 -R

Connecting to host garagebox, port 9000

Reverse mode, remote host garagebox is sending

[ 4] local 192.168.3.104 port 46834 connected to 192.168.3.176 port 9000

[ ID] Interval Transfer Bandwidth

[ 4] 0.00-1.00 sec 98.7 MBytes 828 Mbits/sec

[ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec

[ 4] 2.00-3.00 sec 112 MBytes 936 Mbits/sec

[ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec

[ 4] 4.00-5.00 sec 106 MBytes 886 Mbits/sec

[ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec

[ 4] 6.00-7.00 sec 112 MBytes 936 Mbits/sec

[ 4] 7.00-8.00 sec 112 MBytes 936 Mbits/sec

[ 4] 8.00-9.00 sec 112 MBytes 937 Mbits/sec

[ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-10.00 sec 1.07 GBytes 923 Mbits/sec 52 sender

[ 4] 0.00-10.00 sec 1.07 GBytes 921 Mbits/sec receiver

iperf Done.

root@espressobin:/sys/devices/platform/dsa@0/net# lspci

00:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)

tkaiser · April 23, 2017

'sudo armbianmonitor -u' or it didn't happen!

Seriously: I want to start adding OMV support for it so I would also appreciate getting output from 'cat /proc/cpuinfo' and a 30 second sample from 'sudo armbianmonitor -m' while you start a 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo)' in another shell (should be finished in less than 10 seconds, right?)

lanefu · April 23, 2017

Yeah OMV for this will be amazing. FYI here's the SATA card I bought for it:

Syba 2 Port SATA III Mini PCIe Card Components Other (SD-MPE40056)

http://sprunge.us/ZJPT

bench and cpu-info

Spoiler

root@espressobin:~# sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo)

sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:

Number of threads: 2

Doing CPU performance benchmark

Threads started!

Done.

Maximum prime number checked in CPU test: 20000

Test execution summary:

total time: 23.0851s

total number of events: 10000

total time taken by event execution: 46.1613

per-request statistics:

min: 4.57ms

avg: 4.62ms

max: 20.15ms

approx. 95 percentile: 4.60ms

Threads fairness:

events (avg/stddev): 5000.0000/5.00

execution time (avg/stddev): 23.0806/0.00

root@espressobin:/sys/devices/platform# cat /proc/cpuinfo

processor : 0

BogoMIPS : 25.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32

CPU implementer : 0x41

CPU architecture: 8

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

processor : 1

BogoMIPS : 25.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32

CPU implementer : 0x41

CPU architecture: 8

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

root@espressobin:/sys/devices/platform# armbianmonitor -m

Stop monitoring using [ctrl]-[c]

Time CPU load %cpu %sys %usr %nice %io %irq

16:15:08: 800MHz 0.00 1% 0% 0% 0% 0% 0%

16:15:13: 800MHz 0.00 1% 0% 0% 0% 0% 0%

16:15:19: 800MHz 0.00 1% 0% 0% 0% 0% 0%

16:15:24: 800MHz 0.16 1% 0% 0% 0% 0% 0%

16:15:29: 800MHz 0.31 1% 0% 1% 0% 0% 0%

16:15:34: 800MHz 0.44 2% 0% 1% 0% 0% 0%

16:15:39: 800MHz 0.57 2% 0% 1% 0% 0% 0%

16:15:44: 800MHz 0.52 2% 0% 1% 0% 0% 0%

16:15:49: 800MHz 0.48 2% 0% 1% 0% 0% 0%

16:15:54: 800MHz 0.44 2% 0% 1% 0% 0% 0%

16:15:59: 800MHz 0.41 2% 0% 1% 0% 0% 0%

16:16:04: 800MHz 0.37 2% 0% 1% 0% 0% 0%^C

cpufreq-info

Spoiler

root@espressobin:/sys/devices/platform# cpufreq-info

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009

Report errors and bugs to cpufreq@vger.kernel.org, please.

analyzing CPU 0:

driver: cpufreq-dt

CPUs which run at the same hardware frequency: 0 1

CPUs which need to have their frequency coordinated by software: 0 1

maximum transition latency: 50.0 us.

hardware limits: 200 MHz - 800 MHz

available frequency steps: 200 MHz, 267 MHz, 400 MHz, 800 MHz

available cpufreq governors: ondemand, userspace, performance

current policy: frequency should be within 800 MHz and 800 MHz.

The governor "ondemand" may decide which speed to use

within this range.

current CPU frequency is 800 MHz (asserted by call to hardware).

cpufreq stats: 200 MHz:0.00%, 267 MHz:0.00%, 400 MHz:0.00%, 800 MHz:100.00%

analyzing CPU 1:

driver: cpufreq-dt

CPUs which run at the same hardware frequency: 0 1

CPUs which need to have their frequency coordinated by software: 0 1

maximum transition latency: 50.0 us.

hardware limits: 200 MHz - 800 MHz

available frequency steps: 200 MHz, 267 MHz, 400 MHz, 800 MHz

available cpufreq governors: ondemand, userspace, performance

current policy: frequency should be within 800 MHz and 800 MHz.

The governor "ondemand" may decide which speed to use

within this range.

current CPU frequency is 800 MHz (asserted by call to hardware).

cpufreq stats: 200 MHz:0.00%, 267 MHz:0.00%, 400 MHz:0.00%, 800 MHz:100.00%

lanefu · April 23, 2017

Honestly I think running OMV on this board is gonna be hella disruptive to the world of mini-NAS's for nerds

tkaiser · April 23, 2017

15 minutes ago, lanefu said:

Yeah OMV for this will be amazing.

Well, as soon as you send the PR (please change 'BOARD_NAME="Espressobin"' so that it starts with a capital letter) it's as easy as just uncommenting one line of code in customize.sh and you're done

And with this commit I'm already done with tweaks

lanefu · April 23, 2017

Well, as soon as you send the PR (please change 'BOARD_NAME="Espressobin"' so that it starts with a capital letter) it's as easy as just uncommenting one line of code in customize.sh and you're done

[/url] And with this commit I'm already done with tweaks

ya ill try to tidy things up and send a PR.

theres a few weird things like the interface is literally called wan from the device tree perspective rather than eth0... perhaps because of the topaz switch being in the middle of it. i have a few other questions i need to post. Should i start a more topic appropriate thread elsewhere?

Sent from my SM-G920V using Tapatalk

tkaiser · April 23, 2017

IMO discussion can stay here (this could then later be a nice reference for 'random board bring up issues')

lanefu · April 23, 2017

okay cool.. works for me.. Not ready for PR yet, but here's my branch if you wanna see as it stands

https://github.com/lanefu/lib/tree/espressobin

tkaiser · April 23, 2017

Just a quick comment: seems you get random MAC addresses on every reboot? If that's the case please think about adjusting bootscript and let firstrun do the job. Please see how it's done with Pine64: https://github.com/igorpecovnik/lib/blob/308661e2fe13e763297672091b31fac9efa70303/scripts/firstrun#L241-L243

tkaiser · April 23, 2017

On 22.4.2017 at 4:45 AM, lanefu said:

the espressobin comes with it's own u-boot fork installed on NOR

Ah, I totally forgot this. There's a bootloader in NOR flash so we should pay attention (speaking of armbianEnv.txt contents and nand-sata-install behaviour)

In case you've a full log via serial console it would be great if you could put it to an online pasteboard service.

lanefu · April 24, 2017

10 hours ago, tkaiser said:

Ah, I totally forgot this. There's a bootloader in NOR flash so we should pay attention (speaking of armbianEnv.txt contents and nand-sata-install behaviour)

In case you've a full log via serial console it would be great if you could put it to an online pasteboard service.

I think u-boot hides the SPI from the OS... lsblk seems to appear that way.

console stuff

https://pastebin.com/VeB1yB5k

I finally have an image build that installs the uncompressed Kernel image... took some fiddling. need to explore more stuff with networking.. Since the nics are part of the distributed switch architecture nonsense, they're revealed via device tree and is a little less straightforward. I gotta do some more work for network manager to know they exist.. in the meantime... dhclient wan will do the trick.

Okay I've cleaned up enough to send a PR.

I scribbled a few handy HOWTO notes in a gist to clarify install stuff

tkaiser · April 24, 2017

https://github.com/igorpecovnik/lib/commits/master (please see the changes necessary for OMV)

tkaiser · April 24, 2017

Just for fun: http://kaiser-edv.de/tmp/NumpU8/ (based on kernel 4.4.52 and OMV 3.0.72, default password for both UI and SSH access is 'openmediavault')

Completely untested so in case you give it a try please do some tests and submit output from 'sudo armbianmonitor -u' later. Wrt tests please see http://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=142093#post142093 (I would prefer Helios LanTest numbers)

zador.blood.stained · April 24, 2017

3 hours ago, lanefu said:

I think u-boot hides the SPI from the OS... lsblk seems to appear that way.

SPI flash would be exposed as MTD device, not as block device. And for it you need some options in the kernel config and bindings in DT.

Assuming it's not really "hidden" by making it a secure access only device.

lanefu · April 25, 2017

So next challenges are

* CPU Frequency stuff.. DFS?

* network interface management -- either eliminate network manager for now or like patch it.

Network Manager isn't equiped to deal with the interfaces because they're on a distributed switch. NM does too much low level stuff... I saw a thread from august on a networkmanger bugtracker somewhere also identify that weakness, but it doesnt' look like it's been solved yet.

Spoiler

Apr 25 01:30:41 espressobin NetworkManager[2018]: <info> [1493083841.6741] device (lo): link connected

Apr 25 01:30:41 espressobin NetworkManager[2018]: <info> [1493083841.6789] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)

Apr 25 01:30:41 espressobin NetworkManager[2018]: <info> [1493083841.6871] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)

Apr 25 01:30:41 espressobin NetworkManager[2018]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed

Apr 25 01:30:41 espressobin NetworkManager[2018]: <info> [1493083841.6944] manager: (lan1): new Generic device (/org/freedesktop/NetworkManager/Devices/3)

Apr 25 01:30:41 espressobin NetworkManager[2018]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed

Apr 25 01:30:41 espressobin NetworkManager[2018]: <info> [1493083841.7052] manager: (lan0): new Generic device (/org/freedesktop/NetworkManager/Devices/4)

Apr 25 01:30:41 espressobin NetworkManager[2018]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed

Apr 25 01:30:41 espressobin NetworkManager[2018]: <info> [1493083841.7165] manager: (wan): new Generic device (/org/freedesktop/NetworkManager/Devices/5)

tkaiser · April 25, 2017

4 hours ago, lanefu said:

Network Manager isn't equiped to deal with the interfaces because they're on a distributed switch

I don't think so. You can simply 'blacklist' interfaces you don't want NM to deal with and even if you allow NM to handle allNICs it should be possible to do bridging, routing and so on with NM: https://github.com/armbian/build/commit/e6c47e0b33278cf2735ce111c28a2b30b26c2137#commitcomment-21877390

I think it just needs some time to understand/adopt new/better concepts (applies especially to DSA which I'm still not familiar at all)...

TheLinuxBug · April 28, 2017

Hello All,

I see you are starting to work on Armbian for ESPRESSOBin and that is awesome. I had a question though I was hoping maybe @tkaiser or someone here could answer for me. I am trying to use an M.2 SSD on PCI-e adapter in the PCI-e slot on the board and noticed this doesn't work. A SATA port multiplier works just fine, however when the SSD is installed it seems it can't find the drive device. Now in reading I saw that on the Clearfog it was necessary to rebuild u-boot ( per Here and Here ) to accomplish using the SATA drive because the SERDES lanes need to be reconfigured. However, this is where I run into a bit of an issue -- In this case u-boot is on SPI NOR and from what I can tell Globalscale has not provided links to u-boot source for the board yet (that I could find). As such, I am wondering if it is actually possible to accomplish using an SSD in the PCI-e slot like I am attempting and if so how one would go about finding/patching u-boot and writing it on the SPI NOR device (or possibly boot from SDcard)?

I appreciate any feedback on this that you can provide as I would love to get this working.

Thanks in advance!

Cheers!

lanefu · April 28, 2017

Hello All,

I see you are starting to work on Armbian for ESPRESSOBin and that is awesome. I had a question though I was hoping maybe [mention=7]tkaiser[/mention] or someone here could answer for me. I am trying to use an M.2 SSD on PCI-e adapter in the PCI-e slot on the board and noticed this doesn't work. A SATA port multiplier works just fine, however when the SSD is installed it seems it can't find the drive device. Now in reading I saw that on the Clearfog it was necessary to rebuild u-boot ( per Here and Here ) to accomplish using the SATA drive because the SERDES lanes need to be reconfigured. However, this is where I run into a bit of an issue -- In this case u-boot is on SPI NOR and from what I can tell Globalscale has not provided links to u-boot source for the board yet (that I could find). As such, I am wondering if it is actually possible to accomplish using an SSD in the PCI-e slot like I am attempting and if so how one would go about finding/patching u-boot and writing it on the SPI NOR device (or possibly boot from SDcard)?

I appreciate any feedback on this that you can provide as I would love to get this working.

Thanks in advance!

Cheers!

so espressobin support is in the mainline u-boot 2017.05 rc. I believe Marvell's github repo has the 2013 u-boot branch they use on the board.

as far as updating u-boot on the onboard flash im not sure. all this stuff is pretty new to me.

Sent from my SM-G920V using Tapatalk

tkaiser · April 28, 2017

4 hours ago, TheLinuxBug said:

A SATA port multiplier works just fine, however when the SSD is installed it seems it can't find the drive device.

You put a SATA port multiplier on the mPCIe slot?

Wrt u-boot patches: Nothing needed, you can't do SERDES voodoo on the Espressobin unlike the Clearfogs where mPCIe slots can be turned into mSATA. You should check 'lspci -vnk' since if the device is listed (only SSDs that appear as PCIe devices and not SATA) maybe it's as easy as https://forum.armbian.com/index.php?/topic/4024-low-ethernet-rx-performance-on-clearfog/&do=findComment&comment=29497

TheLinuxBug · April 28, 2017

@tkaiser Actually it may not be a PM, I got the following and it works: http://www.ebay.com/itm/232272531643?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Seems I wasted 22$ on the 32Gb mSATA and PCI-e adapter card, most likely. I didn't try lspci -vnk but lspci was not returning anything when it was inserted.

I will have to swap it out and test again tomorrow and see.

I was looking forward to the SSD as my rootfs :unsure:

Well thanks for the response!

Cheers!

tkaiser · April 28, 2017

4 minutes ago, TheLinuxBug said:

Actually it may not be a PM, I got the following and it works: http://www.ebay.com/itm/232272531643?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

This is not a PM but just a low-end PCIe SATA controller (ASM1061: PCIe 2.x x1 to 2 x SATA). For your mSATA SSD you would need something similar since it can not work directly inside a PCIe slot. The only SSD variants that might work with a mechanical adapter are NVME thingies with an mPCIe to M.2 adapter.

But why rootfs on an el cheapo SSD? Have you tried out my OMV build that has some optimizations to be fine running off an SD card?

Sign In

Espressobin support development efforts

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Similar Content

Important Information