Jump to content
  • 0

Espressobin support development efforts


lanefu
 Share

Question

 

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

Recommended Posts

Check forum guidelines to use maximum potential!

  • 0
26 minutes ago, zador.blood.stained said:

eth*addr values in the u-boot environment? ethernet aliases in the DT so the u-boot sets MAC address properties?

 

Yeah I'm setting then in the u-boot environment.  (on-board u-boot)    I've dug up marvell's u-boot branch and i'm comparing that device tree to whats in the linux version of the device tree but i don't really know what's what.

 

So.. 

 

In the kenrnel DTS we see switch0 adn wan, lan1, and lan2

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts

 

but in u-boot we don't see anothing other than eth0

 

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/armada-3720-espressobin.dts;h=aa6587af667d1dc091f84e12845afeca97df2128;hb=refs/heads/master#l90

 

there's some sort of mismatch between u-boot's access to the interfaces, versus the OS when is connects via switch.

Link to comment
Share on other sites

  • 0
2 minutes ago, zador.blood.stained said:

Hm. I don't think you can assign different MAC addresses to DSA switch ports without ugly hacks, so (mainline) u-boot environment probably doesn't matter.

 

in theory i'm setting the MACs to whats on the sticker from the factory for the 3 interfaces....   i just dont get this u-boot phy phymode dsa stuff very well as a whole

Link to comment
Share on other sites

  • 0
Just now, lanefu said:

in theory i'm setting the MACs to whats on the sticker from the factory for the 3 interfaces....   i just dont get this u-boot phy phymode dsa stuff very well as a whole

Well, u-boot doesn't support DSA at all, so DT in u-boot doesn't have DSA related definitions (though DT may be synced up with the kernel later). On devices like sunxi boards u-boot just sets some DT properties for the kernel to use.

Link to comment
Share on other sites

  • 0
32 minutes ago, Igor said:


You use bridged config?

 

 

okay so actually yes i *JUST* did that.

 

So I bridged lan0,lan1 together.. then i was able to get IP on the bridge interface for that.  Then I was able to also put an IP on the WAN port.

 

I bound an iperf server to EACH interface. and then ran a Iperf test to each interface from 2 different computres capable of doing gig (optiplex workstations)....and..

 

BOOOOOO 1 GIG total.

 

but i think it's totally fixable

 

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts#L145

 

PS I did have to set mac addresses before configuring bridge like so

ip link set wan address F0:AD:4E:03:64:82
ip link set lan0 address F0:AD:4E:03:64:80
ip link set lan1 address F0:AD:4E:03:64:81
 
Edited by lanefu
set mac
Link to comment
Share on other sites

  • 0

Just for the record: We have a SoC talking via RGMII to the onboard switch (currently with 1GbE but maybe 2.5GbE possible). We use DSA to tell the switch to not act as a switch on layer 2 anymore but separate downstream ports to get 3 individual interfaces just to bridge them again at the kernel layer above. Doing this at the DSA layer (telling the switch to be a dumb layer 2 switch accessible as eth0) might save CPU resources and result in better performance if I'm not wrong?

Link to comment
Share on other sites

  • 0
4 hours ago, tkaiser said:

Just for the record: We have a SoC talking via RGMII to the onboard switch (currently with 1GbE but maybe 2.5GbE possible). We use DSA to tell the switch to not act as a switch on layer 2 anymore but separate downstream ports to get 3 individual interfaces just to bridge them again at the kernel layer above. Doing this at the DSA layer (telling the switch to be a dumb layer 2 switch accessible as eth0) might save CPU resources and result in better performance if I'm not wrong?

 

so it looks like the topaz switch needs to be talking to soc via SGMII instead of RGMII to achieve 2.5G..... (or am I just not getting it?)  I wish i understood this DTS nonsense better.  I took a stab at tweaking the bandwidth but that just broke the networking altogether lol

 

omg I might have found something relevant

 

anyway.. yes you're describing the ideal scenario..   

 

i'm doing another build from igor's latest commit.

Link to comment
Share on other sites

  • 0
On 6/13/2017 at 3:17 PM, tkaiser said:

Just for the record: We have a SoC talking via RGMII to the onboard switch (currently with 1GbE but maybe 2.5GbE possible). We use DSA to tell the switch to not act as a switch on layer 2 anymore but separate downstream ports to get 3 individual interfaces just to bridge them again at the kernel layer above. Doing this at the DSA layer (telling the switch to be a dumb layer 2 switch accessible as eth0) might save CPU resources and result in better performance if I'm not wrong?

 

So the only value in bridging the interfaces together is that NetworkManager operates properly and configures the network because it's interacting with the bridge interface instead of the dsa interface.... stupid I know, but that's just still a weakness in networkmanager.

 

But as stupid as it is.. maybe i'll try creating 1:1 Bridges for each interface so that network manager can actually handle networking.   It's a total kludge for sure, but would at least make default armbian build consistent. 

Link to comment
Share on other sites

  • 0
On 4/28/2017 at 2:04 AM, tkaiser said:

 

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?

 

So... i just fired up that image you built 2 months ago.... and .. worked out of hte box... 

 

so i've got 3 drives plugged in... 1 on the built in, and then 2 drives plugged into my add-on.. and all linked at SATA 3

 

[ 1249.682870] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

[ 1250.358973] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

[ 1252.746822] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

 

espressoOMV1.png

Link to comment
Share on other sites

  • 0
1 hour ago, lanefu said:

So the only value in bridging the interfaces together is that NetworkManager operates properly and configures the network because it's interacting with the bridge interface instead of the dsa interface.... stupid I know, but that's just still a weakness in networkmanager.

 

But as stupid as it is.. maybe i'll try creating 1:1 Bridges for each interface so that network manager can actually handle networking.   It's a total kludge for sure, but would at least make default armbian build consistent. 


What if ... disabling network manager altogether and:
 

eth0 / wan = dhcp

lan0 and lan1 interfaces into bridge interface br0 with the static IP, masquerading through the wan interface, and both have IP forwarding enabled.

dhcp server on br0

Link to comment
Share on other sites

  • 0
8 minutes ago, Igor said:

What if ... disabling network manager altogether and:
 

eth0 / wan = dhcp

lan0 and lan1 interfaces into bridge interface br0 with the static IP, masquerading through the wan interface, and both have IP forwarding enabled.

dhcp server on br0

 

yeah disabling network manager is probably a step in the right direction.

 

re: lan interfaces... i think generally that's a good default, although for safety, i would configure DHCP server, but not enable the service by default.   

 

I'm also trying to wrap my head around the true potential of the interfaces....   This post makes me think i can only get a gig in and out of the CPU.   

Link to comment
Share on other sites

  • 0

...and I think i'm officially convinced that the max bandwidth between topaz switch and cpu is in fact 1gigabit...   The connection is using a seperate RGMII lane. (eth0)

 

eth1 -- would be the interface capable of of SGMII, but the 3 fast lanes are occupied with USB, MiniPCI and SATA

 

this guy says so

 

Link to comment
Share on other sites

  • 0

Okay.... I built a new OMV image last night... Frequency Scaling is working.. sweet

 

So I need some helio tests to smb. Using my MBP w/ Thunderbolt gig NIC . to cheap SANDisk X300... I did onboard sata.. and another testing with my add-on sata card.

 

no bad at all.   Writes seem to be thread bound by samba.   This was traversing accross my 48port POE switch, not point to point.. same vlan.

 

@tkaiser OMV is promising.

 

I had tested some raid 5 stuff, but turns out i had a bad sata cable causing my woes

 

SSDAddOnPCIeControllerNoCacheSMB.png

SSDOnboardNoCacheSMB.png

Link to comment
Share on other sites

  • 0
5 minutes ago, lanefu said:

So I need some helio tests to smb

 

Not the best idea since the stock Debian Samba package used in OMV3 lacks some important (and performance relevant) features needed by macOS clients (I tried to explain that to OMV devs but got not that encouraging responses so I decided to step back at the moment instead of suggesting improvements): https://bugs.pcbsd.org/issues/5904

 

You get Netatalk installed/configured within 5 minutes, it's just adding this as Extra, then activating AFP and creating an AFP share. Write performance will improve a lot!

 

Off-topic tip for screenshots: [shift]-[cmd]-[4] --> hover over the window you want to capture --> [space] --> mouse click. You end up with a nice screenshot only showing the window with transparent background including a shadow.

Link to comment
Share on other sites

  • 0

i searched for afp for like 2 seconds and couldnt find the plugin..
fiddled with nfs too... so many knobs to turn..
anyway the bad numbers are pretty good

Sent from my SM-G920V using Tapatalk

Link to comment
Share on other sites

  • 0
3 minutes ago, lanefu said:

anyway the bad numbers are pretty good

 

Sure, but they need to get better! :)

 

Off-topic 2: that's what I do for a living sometimes:



This is what those guys transferring more data each day than the rest of the company within a year (graphics department) suffer from:

Win_2012.png

Now replacing the f*cking expensive Win2012 server box with a cheap Linux box using Samba and appropriate settings ('Gigabit Ethernet settings' like above show 72/80 MB/s on same hardware with same settings):

Samba_SerNet_Share_Enterprise.png

Link to comment
Share on other sites

  • 0

Hi,

 

for the records, the ESPRESSObin runs pretty well with a 4.12-rc mainline kernel. I've merged the marvell defconfig with upstream defconfig, but I needed to skip CONFIG_DRM* (otherwise board doesn't boot). Following things are missing at the moment:

  • cpu frequency scaling
  • wlan0 (didn't manage to get I working with 4.4 BSP)
  • mtd access (didn't manage to get I working with 4.4 BSP either)
  • USB 2.0 port (while the USB 3.0 runs fine)

Did anyone here succeed in getting wlan and/or mtd running?

 

Cheers

Uli

Link to comment
Share on other sites

  • 0
10 hours ago, lanefu said:

whats mtd?
 

It's where the firmware and the u-boot environment are stored. The u-boot-tools package contains some utilities to read/modify the u-boot environment which is much more comfortable then in the interactive u-boot shell. 

Link to comment
Share on other sites

  • 0
On 26.6.2017 at 9:04 PM, Igor said:


I tested two mPCI wireless adaptors (ath9 and ath10) on 4.4.x and none was recognised. 

I've booted the buildroot rootfs mentioned here and recognized that the ESPRESSObin was shipped with a Marvell wifi card:

[    6.443748] mwifiex_pcie: try set_consistent_dma_mask(32)
[    6.443832] mwifiex_pcie: PCI memory map Virt0: ffff000009700000 PCI memory map Virt2: ffff000009900000
[    6.443984] mwifiex: rx work enabled, cpus 2
...
[    7.864608] mwifiex_pcie 0000:00:00.0: info: FW download over, size 803884 bytes
[    8.618814] mwifiex_pcie 0000:00:00.0: WLAN FW is active
[    8.689914] mwifiex_pcie 0000:00:00.0: CMD_RESP: cmd 0x242 error, result=0x2
[    8.689932] mwifiex_pcie 0000:00:00.0: mwifiex_process_cmdresp: cmd 0x242 failed during      initialization
[    8.720109] mwifiex_pcie 0000:00:00.0: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p53)
[    8.720120] mwifiex_pcie 0000:00:00.0: driver_version = mwifiex 1.0 (15.68.7.p53)

I've pushed the latest mvebu_v8_lsp_defconfig to my kernel source tree (you will find the other patches there as well).

Link to comment
Share on other sites

  • 0
On 28.6.2017 at 4:04 AM, lanefu said:

Quick AFP test over PCI Sata card...  Not quite what I expected... better latency on small stuff, but raw throughput was faster with SMB

 

Nope, you just tested two different things (one time with 'Gigabit Ethernet' and the other with 'Enterprise network' settings -- that's not just only 300 MB vs. 3000 MB test file size but more importantly 128K vs. 1M test block size -- and with SMB you used 1MB while just 128K with AFP now).

 

I bet it will also make a slight difference whether the SSD is on the real SATA port or connected to the ASM1062.

Link to comment
Share on other sites

  • 0
6 minutes ago, tkaiser said:

 

Nope, you just tested two different things (one time with 'Gigabit Ethernet' and the other with 'Enterprise network' settings -- that's not just only 300 MB vs. 3000 MB test file size but more importantly 128K vs. 1M test block size -- and with SMB you used 1MB while just 128K with AFP now).

 

I bet it will also make a slight difference whether the SSD is on the real SATA port or connected to the ASM1062.

 

doh.  iSuk.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...