Jump to content

Espressobin support development efforts

lanefu

By lanefu
in Marvell mvebu

 Share

Recommended Posts

nurF

nurF

Posted
Posted

Does anyone know, what is causing the following error message? 

sdhci_transfer_data: Error detected in status(0x2008000)!                                                             
Error reading cluster                                        
** Unable to read file armada-3720-espressobin.dtb **

 

0
briaeros

briaeros

Posted
Posted

Hello,

 

First, thanks for your time in creating and managing armbian :)

 

It will be great if cryptsetup work "out of the box"  (without rebuilding your own kernel) (at least in devel ;)).

At the present time, I can't mount any encrypted partition because some options are missing in the kernel.

I think the kernel option "CONFIG_CRYPTO_USER_API_SKCIPHER" is needed.

The module dm_mod.ko is also needed but I can't find which option(s) creates it (it's the device mapper module).

 

 

It will be also great if we can try the CESA code since the option seems here (CONFIG_CRYPTO_DEV_MARVELL_CESA)  , so we can test it :)

 

I paste below the results of my simple tests.

 

  Quote

root@espressobin:~# uname  -a
Linux espressobin 4.16.15-mvebu64 #152 SMP PREEMPT Tue Jun 12 01:48:50 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
root@espressobin:~# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       121362 iterations per second
PBKDF2-sha256      74898 iterations per second
PBKDF2-sha512      68337 iterations per second
PBKDF2-ripemd160  108683 iterations per second
PBKDF2-whirlpool   24380 iterations per second
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.
root@espressobin:~# dd if=/dev/zero of=/run/test bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0315174 s, 333 MB/s
root@espressobin:~# cryptsetup open --type plain /run/test test
Enter passphrase: 
Cannot initialize device-mapper. Is dm_mod kernel module loaded?
root@espressobin:~# cryptsetup luksFormat --type luks2 /run/test

WARNING!
========
This will overwrite data on /run/test irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase: 
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

Expand  

 

0
Igor

Igor

Posted
Posted (edited)
  On 6/15/2018 at 6:01 PM, briaeros said:

First, thanks for your time in creating and managing armbian :)

 

It will be great if cryptsetup work "out of the box"  (without rebuilding your own kernel) (at least in devel ;)).

Expand  

 

Thank you! But only together we can manage with the complexity :) If any kernel config changes are needed, we urge people to send PR against build engine. You can find Espressobin, kernel family mvebu64, configurations here: https://github.com/armbian/build/tree/master/config/kernel ... and general howto here: https://docs.armbian.com/Process_Contribute/

 

Changes lands to the beta.armbian.com package repository in less than 24h if all kernels building succeeded.

 

Try.

Edited by Igor
typo
0
ebin-dev

ebin-dev

Posted
Posted
  On 6/15/2018 at 6:01 PM, briaeros said:

It will be also great if we can try the CESA code since the option seems here (CONFIG_CRYPTO_DEV_MARVELL_CESA)  , so we can test it :)

Expand  

 

The 5Gbps Security Engine of the Espressoin is not CESA compatible. It needs a specific driver implemented by Bootlin in kernel 4.16:

 

  Quote

The driver currently supports:

Hashes: sha1, hmac(sha1), sha224, sha256.
Ciphers: ecb(aes), cbc(aes).

This allows to offload some IPsec connexions, depending on the
configuration, as these algs can be combined by the crypto layer.

More algs are coming, but there is no schedule for them.

Expand  

 

0
briaeros

briaeros

Posted
Posted
  On 6/17/2018 at 6:03 AM, ebin-dev said:

 

The 5Gbps Security Engine of the Espressoin is not CESA compatible. It needs a specific driver implemented by Bootlin in kernel 4.16:

 

 

Expand  

Thanks for the correction. I don't remember where I read that it was CESA. An untrustworthy source certainly.

 

safeexecel is already compiled as a module. I will then try to make it works with my espresso ;)

 

0
arthurlutz

arthurlutz

Posted
Posted

Hi,

 

This read is getting a bit too long and thus it is getting hard to find information in it. Am up for helping on extracting some of the information here and compiling it in a wiki or other type of shared document to help the espressobin community. Anyone else think this is a good idea ? And maybe new threads per subject could be openned ? Does this forum have a habit of using the lock feature on posts that are too long ?

 

By the way, I've asked a question about "[Espressobin] Transparent monitoring switch - ethernet bridge and hardware questions" that might interest some of the espressobin owners.

 

0
Igor

Igor

Posted
Posted
  On 6/25/2018 at 11:09 AM, arthurlutz said:

This read is getting a bit too long and thus it is getting hard to find information in it.

Expand  


It's planned to create a separate forum for Armada powered devices, it's planned to upgrade a kernel for Espresso ... but we extremely lack time/resources for that. If you volunteer to get this forum mess in order by taking moderator duties and move topics into new subforum/in order ... this problem might be already solved. The offer contains editorial rights for this: https://www.armbian.com/espressobin/

0
lampra

lampra

Posted
Posted

On Armbian_5.50_Espressobin_Debian_stretch_next_4.17.3 (either clean install or upgrade) , there is an issue with the network when both lan ports are connected to the same router. This was not the case in the previous (5.44) image.

Demsg is flooded with: 

br0: received packet on lan1 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)
br0: received packet on lan0 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)

and the bridge does not come up.

By the way, has anyone any working bonding setup for lan0 & lan1?

 

0
lanefu

lanefu

Posted
  • Author
Posted

You're effectively introducing a layer2 switch loop when plugging them both in. It was mostly good fortune when it worked previously.


Unfortunately because of the way the espressobin's onboard switch connects to the cpu (sgmi) peak network io to cpu would be 1 gig.


There's dialog about the espressobin's network limitations earlier in the thread. Its kind of a bummer for sure.

  On 7/2/2018 at 8:36 PM, lampra said:
On Armbian_5.50_Espressobin_Debian_stretch_next_4.17.3 (either clean install or upgrade) , there is an issue with the network when both lan ports are connected to the same router. This was not the case in the previous (5.44) image.
Demsg is flooded with:
br0: received packet on lan1 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)br0: received packet on lan0 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)

and the bridge does not come up.
By the way, has anyone any working bonding setup for lan0 & lan1?
 



Sent from my SM-G950U using Tapatalk

0
Tazz

Tazz

Posted
Posted

For those who want to run at 1.2ghz, if you have not noticed you need this:

https://marc.info/?l=linux-arm-kernel&m=152941191324122&w=2

2
y52

y52

Posted
Posted

I've discovered more bugs in the current Armbian build, which, I believe, was inherited from Debian 9 and the network card buggy driver.

1) is related with the segmentation-offload, which is pretty well reproducible :

root@espressobin:~# tcpdump -ni any -s100 -vvv port 53
27.49.62.17.52256 > 212.27.40.240.53: [bad udp cksum 0x5932 -> 0x332d!] 33775+% [1au] DS? akamaiedge.net. ar: . OPT UDPsize=4096 DO (43)

2) was very difficult to figure out, and the solution is not yet clear. It appears, that systemd-network is not properly handling the ipv4 and ipv6 renewals, which results in the wan network access failure periodically on the ISP ip lease renewal. It was very annoying and caused serious argues with the ISP support. The last working hypothesis is that the ipv6 Router Advertisement causes the networkd-[iface] service to fail and therefore the dhcpv4 client is killed too.

3) I also experienced the trouble with the wan interface automatic start up at boot time. Many experience it as well, which also looks to be a systemd-network trouble. It should work out of the box, but at the current state, the end-user has to adjust those setbacks with additional custom-made services or rc.local commads.

 

0
y52

y52

Posted
Posted
  On 7/9/2018 at 5:18 PM, Igor said:

For those who want to run at 1.2ghz, if you have not noticed you need this:

https://marc.info/?l=linux-arm-kernel&m=152941191324122&w=2

 apt update & upgrade will also do :)

https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789

Expand  

This is quite encouraging to finally get the so much advertised CPU clocking.  Has this patch been implemented to the legacy kernel as well? Should the u-boot flash be updated at the same time?

0
Igor

Igor

Posted
Posted
  On 7/10/2018 at 9:20 PM, y52 said:

Has this patch been implemented to the legacy kernel as well?

Expand  


No. I am not sure we want to waste time with that kernel. Feel free to test and submit a patch. I can't.
 

  On 7/10/2018 at 9:20 PM, y52 said:

Should the u-boot flash be updated at the same time?

Expand  


(correct) U-boot (for your board) should be updated in any case.

0
y52

y52

Posted
Posted
  On 7/11/2018 at 5:09 AM, Igor said:

>Has this patch been implemented to the legacy kernel as well?

No. I am not sure we want to waste time with that kernel. Feel free to test and submit a patch. I can't.

Expand  

This is sad.  My board just doesn't stay stable with the "-next" kernel, although I wanted to migrate to it. In my case, the board stability also depends significantly on the .dtb file as well. It appears, that the only stable configuration is the legacy kernel and the 

# DTB submitted by GlobalScaleTech. Stable.
setenv fdt_name_a boot/dtb/marvell/armada-3720-community-v5.dtb
# DTB submitted by Armbian. Unstable.
#setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb

 

Anyway, I can still try the "-next" kernel again with the new patch. Should I understand it correctly, that the "1.2ghz" is already implemented in the "next tree" ?

 

Pls confirm the algorithm to migrate from the legacy tree to the  "next tree" under "1.2ghz".

If I understand it, the following procedure should be applied:

1.  apt update & upgrade with the current  legacy 4.4.138-mvebu64 kernel

2.  armbian-config -> system -> switch to alternative kernel -> next

3.  1200 Mhz u-boot flashing

4. reboot with 1200 Mhz CPU clock under the  "next tree" kernel.

Should anything else be done?

0
Igor

Igor

Posted
Posted
  On 7/11/2018 at 5:53 AM, y52 said:

This is sad.  My board just doesn't stay stable with the "-next" kernel

Expand  


I am also sad, but for other reasons. Remember. This is not a professional support service and I need to save our resources to be able to work on things that make us happy.

 

The same you need to do on a legacy kernel: https://github.com/armbian/build/commit/5823d40016d2fd522dba5f75af2ec14bfc6986a3 

But implementation might be different and perhaps you will need to adjust patches. Then you need to build and test. One could lose an hour or a day.  If you are unable to do this, hire someone.
 

  On 7/11/2018 at 5:53 AM, y52 said:

Should anything else be done?

Expand  


1 & 2 yes

3 & 4 follow the procedure written at the download page. Flash u-boot with correct numbers. 1200Mhz tells me nothing at this point. Just don't go with higher numbers than what you have now and expect that the board will boot and be stable.

0
Jens Bauer

Jens Bauer

Posted
Posted
  On 4/15/2018 at 5:11 PM, ebin-dev said:

 

Debian server - mainline kernel - make sure you are on the stable branch and update your system with 'apt-get update && apt-get upgrade'.

Expand  

Using Ubuntu, I just found out during the last three days that if I do a fresh install of 5.50 on my EspressoBIN and as the first thing issue apt-get update && apt-get upgrade, followed by a reboot, then the network will never come up and I'll have to log in using a serial console.

0
ebin-dev

ebin-dev

Posted
Posted
  On 7/14/2018 at 6:27 AM, Jens Bauer said:

Using Ubuntu, I just found out during the last three days that if I do a fresh install of 5.50 on my EspressoBIN and as the first thing issue apt-get update && apt-get upgrade, followed by a reboot, then the network will never come up and I'll have to log in using a serial console.

Expand  

Do you have the same problem with Debian - mainline/stable ?

If not - then the issue is very likely caused by the systemd-networkd implementation chosen by Ubuntu ...

0
Jens Bauer

Jens Bauer

Posted
Posted
  On 7/14/2018 at 8:09 AM, ebin-dev said:

Do you have the same problem with Debian - mainline/stable ?

 If not - then the issue is very likely caused by the systemd-networkd implementation chosen by Ubuntu ...

Expand  

I haven't tried debian - and I do not have much time on my hand, because my server needs to be set up completely within a few days, as I'm going back home. Sadly, it seems the Ubuntu I'm running does not allow me to "reboot" without hanging, so I can't maintain much via SSH from home (because it'll cost me 6 hours to travel each way plus around $200, which I currently cannot afford). -I just thought I'd like to mention this, so that others will have fewer problems and the maintainers may know about it.

0
Jens Bauer

Jens Bauer

Posted
Posted
  On 7/14/2018 at 8:09 AM, ebin-dev said:

Do you have the same problem with Debian - mainline/stable ?

 If not - then the issue is very likely caused by the systemd-networkd implementation chosen by Ubuntu ...

Expand  

 

Yesterday, I recorded the commands and the outputs ...

  Reveal hidden contents

-All I can see about systemd is 'processing triggers for systemd', so I'm not sure systemd is at fault directly.

I can see a lot of library updates, so I would expect that this could be caused by an updated library that systemd is using.

-only a simple guess, though.

0
y52

y52

Posted
Posted
  On 7/14/2018 at 1:52 PM, Jens Bauer said:

the issue is very likely caused by the systemd-networkd implementation

Expand  

systemd remains quite buggy. I try finding workarounds for it's different issues.

I suggest modifying as follows the

/lib/systemd/system/systemd-networkd.service

 

[Service]
Type=notify
Restart=on-failure
RestartSec=0
# https://www.toradex.com/community/questions/1144/weird-behavior-when-restarting-networkd.html
ExecStartPre=/sbin/ip addr flush dev wan
ExecStartPre=/sbin/ip link set wan down
ExecStartPre=/sbin/ip link set wan up
ExecStart=!!/lib/systemd/systemd-networkd

 

 

There is also a bad behavior in inability acquiring the DHCPv6 lease when hot restarting the systemd-networkd without rebooting.

Where could kernel configs (for mainline and legacy trees) be found to double check if the following settings are similar as below ?

-# CONFIG_IPV6_MULTIPLE_TABLES is not set
+CONFIG_IPV6_MULTIPLE_TABLES=y
-# CONFIG_IPV6_MROUTE_MULTIPLE_TABLES is not set
+CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y

 

 

 

0
lampra

lampra

Posted
Posted

Am I missing something?

I tried to install wireguard in the prebuild images but i failed using the linux-headers-next-mvebu64 package.

Today I compiled a mainline image with headers installed but I still fail to install wireguard. Here is the log

  Reveal hidden contents

I have read in this that we need to call make scripts. Here is the output

  Reveal hidden contents

Edit: Diagnostics

 

0
lampra

lampra

Posted
Posted
  On 7/18/2018 at 7:27 AM, Igor said:

Try without DKMS.
 

Expand  

Compilation from source also not working:

  Reveal hidden contents

 

 

0
Igor

Igor

Posted
Posted

 

  On 7/18/2018 at 4:40 PM, lampra said:

Compilation from source also not working:

Expand  


Headers are not source. We pack kernel source but don't upload it to the repository due to space limits.

 

So far I don't see any problem on Armbian side except DKMS might be broken ... but that is not essential to compile a module.

0
lampra

lampra

Posted
Posted
  On 7/18/2018 at 4:47 PM, Igor said:

Headers are not source. We pack kernel source but don't upload it to the repository due to space limits.

So far I don't see any problem on Armbian side except DKMS might be broken ... but that is not essential to compile a module.

Expand  

Well the module is compiled and installation finishes but when I am trying to use wireguard it fails and the output seems to point to wrong or missing kernel headers 

# wg-quick up wg0
[#] ip link add wg0 type wireguard
RTNETLINK answers: Operation not supported
Unable to access interface: Protocol not supported

What i noticed is that after installation, a new folder is created in /lib/modules/ where wireguard.ko is placed 

$ ls /lib/modules/
4.17.7  4.17.7-mvebu64
$ ls /lib/modules/4.17.7/extra/
wireguard.ko

 

 

0

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
Reply to this topic...

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

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept