OMG i'm googling and the only hits I'm getting are my own freaking posts and my own gist

1 hour ago, lanefu said:

having some problems now where all interfaces are taking the same MAC..... i *know* had this working a while back.. even being weird on my build now..... debugging

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

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.

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.

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

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.

3 hours ago, lanefu said:

having some problems now where all interfaces are taking the same MAC.....

You use bridged config?

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 June 13, 20179 yr by lanefu
set mac

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?

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.

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. 

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)

 

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

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.   

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

 

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

 

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.

@lanefu if you would like to provide a link to your new image I would be happy to give it a test run (have the ESPRESSOBin sitting on the table in front of me)... just let me know.

 

Cheers!

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

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:



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):

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

Just now, umiddelb said:

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

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

This post here gave me USB 2.0 and mtd access.

whats mtd?

Sent from my SM-G920V using Tapatalk

6 hours ago, lanefu said:

whats mtd?

A kernel layer (subsystem) for accessing raw NAND and NOR flash based storage.

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. 

@tkaiser

 

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

 

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

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.

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.