Espressobin support development efforts
11 11

246 posts in this topic

Recommended Posts

 

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 by zador.blood.stained
Renamed to reflect the contents

Share this post


Link to post
Share on other sites

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 likes this

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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 by lanefu
sounding less stupid
tkaiser likes this

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

espressobin-2017-04-22.thumb.png.fef179cbea490d6cf587be04af3e8f29.png

tkaiser and Igor like this

Share this post


Link to post
Share on other sites

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)

 

 

Share this post


Link to post
Share on other sites

'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?)

Share this post


Link to post
Share on other sites

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%

 

 

 

Share this post


Link to post
Share on other sites
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 :) 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites
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 likes this

Share this post


Link to post
Share on other sites

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)

 

 

Share this post


Link to post
Share on other sites
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)...

lanefu likes this

Share this post


Link to post
Share on other sites

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!

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

11 11

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.