Espressobin support development efforts

[Igor]

5 hours ago, chrisf said:

I saw the announcement by @Igor of the RT kernel for this board, based off the 4.13.10 mainline kernel. Is there going to be a regular mainline build? @ebin-dev said there was work for the new hardware crypto engine begin done for mainline as well.

I moved NEXT yesterday to 4.14.y and DEV is linked to mainline. Kernels are(will be) available in the beta repository. Currently no major if any advance. At least SD card is not recognized ... so booting from USB3 is mandatory.

[ebin-dev]

4 hours ago, Igor said:

I moved NEXT yesterday to 4.14.y and DEV is linked to mainline. Kernels are(will be) available in the beta repository. Currently no major if any advance. At least SD card is not recognized ... so booting from USB3 is mandatory.

 

@Igor Thank you for the update. I have just contacted our friends from Free Electrons - support for the Marvell Security Engine of the EspressoBin is probably finished within the next weeks and is exprected to be part of the crypto tree in Mainline 4.16. I`ll keep you informed.

 

I have just updated my EspressoBin with the latest nightly builds: unfortunately 'armbian-config' has disappeared - is someone working on it ?

[Igor]

2 hours ago, ebin-dev said:

I have just updated my EspressoBin with the latest nightly builds: unfortunately 'armbian-config' has disappeared - is someone working on it ?

It's now packed separately. I'll check ...

[zador.blood.stained]

49 minutes ago, Igor said:

It's now packed separately.

Exactly. I'll modify the armbian-config MOTD script to show that it can be installed with "apt install armbian-config"

[umiddelb]

13 hours ago, Igor said:

I moved NEXT yesterday to 4.14.y and DEV is linked to mainline. Kernels are(will be) available in the beta repository. Currently no major if any advance. At least SD card is not recognized ... so booting from USB3 is mandatory.

 

Hm, 4.14. comes with SD card support for the espressobin (no additional patch needed).

[Igor]

On 15. 11. 2017 at 8:43 PM, umiddelb said:

Hm, 4.14. comes with SD card support for the espressobin (no additional patch needed).

I moved to mainline source. Should I rather go back?

[chrisf]

I just tried both next and dev, neither have SD card support.

 

[umiddelb]

I'm using a different defconfig to build my kernel. It's derived from one of the first Marvell 4.4 kernel sources with arm64 platform defaults and Docker requirements added. I know that Armbian uses a different one. I started to merge both configs but that kernel didn't boot up. I've started some bisects but didn't find the time to identify all problematic kernel parameters.  

[chrisf]

I've compared the kernel config for mainline and Marvell's 4.4 and one thing that stands out in regards to the SD card issue is:

CONFIG_MMC_SDHCI_XENON

In the linux-mvebu64-default.config it is set to y, in linux-mvebu64-next.config is it not set

 

That could explain why it works to @umiddelb, his defconfig has it enabled too. I'll try it myself when I get the chance but that could be a few days away.

 

Edit:

I've just tried it on next and it works, just need to update fdt_name env var to point to the correct DTB

# uname -a
Linux ebin 4.14.0-mvebu64 #4 SMP PREEMPT Mon Nov 20 08:02:32 UTC 2017 aarch64 GNU/Linux
# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1  1.4T  0 disk
└─sda1        8:1    1  1.4T  0 part
mtdblock0    31:0    0    4M  0 disk
mmcblk0     179:0    0 29.8G  0 disk
└─mmcblk0p1 179:1    0 29.5G  0 part /

 

Edited November 20, 2017 by chrisf

[Patrick]

I've ARMBIAN 5.34.171121 nightly Debian GNU/Linux 9 (stretch) 4.4.99-mvebu64 running on my ESPRESSObin. I've also an external harddrive in this enclosure: http://www.orico.cc/goods.php?id=6351

When I connect it to my USB2.0 port, the drive is recognized but on the USB3.0 port it's not recognized. When I plugin an USB2.0 thumb-drive in the USB3.0 port it's recognized.

 

Is there something  can try?

 

kr.,

Patrick 

[tkaiser]

13 minutes ago, Patrick said:

http://www.orico.cc/goods.php?id=6351

 

Controller: NS1068X -- that's the problem. This thing needs UAS blacklisting so please try the following: Attach it to your EspressoBin when powered down. Boot once then reboot, then provide output from 'sudo armbianmonitor -u'. Takes you 3 minutes maximum.

[Patrick]

9 minutes ago, tkaiser said:

 

Controller: NS1068X -- that's the problem. This thing needs UAS blacklisting so please try the following: Attach it to your EspressoBin when powered down. Boot once then reboot, then provide output from 'sudo armbianmonitor -u'. Takes you 3 minutes maximum.

Thanks,

 

The results of 'sudo armbianmonitor -u' are uploaded to: http://sprunge.us/UUCX

 

kr.,

Patrick

[tkaiser]

18 minutes ago, Patrick said:

http://sprunge.us/UUCX

 

Ok, the chipset is UAS blacklisted (see 'usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u')

 

41 minutes ago, Patrick said:

When I connect it to my USB2.0 port, the drive is recognized

 

There's not a single occurence of this device in the log except of

[    4.664115] usb 2-1: new full-speed USB device number 2 using xhci-hcd
[    4.671224] xhci-hcd d0058000.usb3: ERROR: unexpected setup context command completion code 0x11.
[    4.680683] usb 2-1: hub failed to enable device, error -22

But you said it's recognized when connecting to the USB2 port. But there's nothing. Anyway, this Norelsys chipset is crap, at least combined with Linux (I bought two of these things by accident few months ago -- advertised as good JMS578 -- and donated one in the meantime to UAS maintainer. But the problem according to log is not only related to UAS).

 

I hope you are aware that the USB3-A connector is somewhat problematic? You need full force to insert jacks into receptacles otherwise SuperSpeed data lines can be troublesome...

[Patrick]

18 minutes ago, tkaiser said:

 
There's not a single occurence of this device in the log except of

[    4.664115] usb 2-1: new full-speed USB device number 2 using xhci-hcd[    4.671224] xhci-hcd d0058000.usb3: ERROR: unexpected setup context command completion code 0x11.[    4.680683] usb 2-1: hub failed to enable device, error -22

 

But you said it's recognized when connecting to the USB2 port. But there's nothing. Anyway, this Norelsys chipset is crap, at least combined with Linux (I bought two of these things by accident few months ago -- advertised as good JMS578 -- and donated one in the meantime to UAS maintainer. But the problem according to log is not only related to UAS).
 
I hope you are aware that the USB3-A connector is somewhat problematic? You need full force to insert jacks into receptacles otherwise SuperSpeed data lines can be troublesome...

 

Sorry,

When I ran the test, the drive was connected to the USB3 port.

Here it's connected to the USB2 port: http://sprunge.us/hFfT


kr.,

Patrick

 

[tkaiser]

30 minutes ago, Patrick said:

Here it's connected to the USB2 port: http://sprunge.us/hFfT

 

Yep, there it is:

    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Unfortunately this kernel (and 23 other Armbian kernels) missed a bit more USB verbosity (fixed now) so with next nightly image or when you update tomorrow from beta repository there might be a little bit more in the logs. But it won't change that much since with this kernel (XHCI / USB3 host controller) the Norelsys thingie will cause problems. Might be fixed with mainline kernel (no idea, never tried) but the best you could do with Norelsys enclosures is to avoid connecting them to Linux hosts anyway or use USB2.

[Patrick]

57 minutes ago, tkaiser said:

 
Yep, there it is:

    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M

 

Unfortunately this kernel (and 23 other Armbian kernels) missed a bit more USB verbosity (fixed now) so with next nightly image or when you update tomorrow from beta repository there might be a little bit more in the logs. But it won't change that much since with this kernel (XHCI / USB3 host controller) the Norelsys thingie will cause problems. Might be fixed with mainline kernel (no idea, never tried) but the best you could do with Norelsys enclosures is to avoid connecting them to Linux hosts anyway or use USB2.

 

Thanks for your help.
I'll avoid this combination for now and use sata instead.

Kr.,
Patrick


Verzonden vanaf mijn iPhone met Tapatalk

 

[Smurfix]

The current -next version works for me. Lots of thanks, everybody.

 

One problem, however: no CONFIG_REGULATOR_ARMADA3700 option in the kernel, hence (I assume) no cpufreq support. Which is not cool – literally, as some of the ICs get quite hot.

 

Is it possible to change that? I'd be OK with lowering the frequency permanently at u-boot time.

[Smurfix]

NB: Building modules on the target doesn't work because some programs in kernel_headers/scripts/simple and …/mod need to be compiled (for the target) and included in the kernel-headers package.

[arm-push]

4 hours ago, Smurfix said:

NB: Building modules on the target doesn't work because some programs in kernel_headers/scripts/simple and …/mod need to be compiled (for the target) and included in the kernel-headers package.

 

You should try this,

 

[Smurfix]

I do not want to know how to build my own kernel inside a virtualbox or whatever.
I want the kernel packages thus built to be usable for everything they're supposed to be usable.

This means that the generated kernel-headers package is required to contain a couple of binaries which are required to build new modules on the target. Specifically:

/usr/src/linux-headers-4.14.2-mvebu64/scripts/basic/bin2c
/usr/src/linux-headers-4.14.2-mvebu64/scripts/basic/fixdep
/usr/src/linux-headers-4.14.2-mvebu64/scripts/mod/modpost

need to be present for dkms (and other methods to build modules out of tree) to work.

[Smurfix]

Ah. Found it. The package requires a "make scripts" to be executed in /usr/src/linux-headers-*, which should be done in postinst but isn't (or dies silently).

Issue #830 filed.

[dhewg]

Hi there,

 

the bootloader binaries hosted here: https://dl.armbian.com/espressobin/u-boot/

Could you please enable CONFIG_DISTRO_DEFAULTS?

 

Thanks

[chrisf]

Is there any reason the nightly builds for this board stopped on the 20th of November?

https://dl.armbian.com/espressobin/nightly/ has builds for 2017-11-19 and 2017-11-20

[ebin-dev]

On 12/14/2017 at 9:27 PM, chrisf said:

Is there any reason the nightly builds for this board stopped on the 20th of November?

https://dl.armbian.com/espressobin/nightly/ has builds for 2017-11-19 and 2017-11-20

 

@Igor @tkaiser Since the nightly builds for the EspressoBin stopped to appear on Nov. 20th I switched to the stable branch. The latest stable legacy kernel images (4.4.102) were created on December 4th. I could not find any upstream patches at least for the EspressoBin since then (kernel 4.4.107 would be up to date). 

 

Is there anything broken by one of the more recent kernel patches ?

 

I am currently using "ARMBIAN 5.36 user-built Debian GNU/Linux 9 (stretch) 4.4.102-mvebu64". It works flawlessly and provides cloud services and other stuff at home.

[Igor]

1 hour ago, ebin-dev said:

Since the nightly builds for the EspressoBin stopped to appear on Nov. 20th I switched to the stable branch

 

Nightly building is back.
https://beta.armbian.com/pool/main/l/linux-4.14.7-mvebu64/

[dhewg]

On 11/28/2017 at 3:07 PM, andre. said:

Hi there,

 

the bootloader binaries hosted here: https://dl.armbian.com/espressobin/u-boot/

Could you please enable CONFIG_DISTRO_DEFAULTS?

 

Thanks

Realizing it's not that easy, I implemented the missing pieces for the generic distro concept.

They'll be part of an upcoming release (mainline as well as marvell's).

 

Bottom line: one can now use boot.scr to load raw kernel/initrd as with many other platforms.

 

It works fine with plain debian and it's flash-kernel. I guess armbian could make use of it too:

https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boot-2017.03-armada-17.10

[Igor]

3 minutes ago, andre. said:

one can now use boot.scr to load raw kernel/initrd as with many other platforms.

I don't understand what you mean by that? boot.scr loading is already implemented since months.

[dhewg]

2 minutes ago, Igor said:

I don't understand what you mean by that? boot.scr loading is already implemented since months.

Sorry, I meant generic boot scripts. Now you don't have to generate FIT image, u-boot is able to load raw compressed initrd's and its trying all available boot devices (mmc1, mmc0, usb, scsi, pxe, dhcp).

 

See http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro

[Patrick]

Hello,

 

First of all the best wishes for 2018 to everyone!

 

I'm running "ARMBIAN 5.37.171231 nightly Debian GNU/Linux 9 (stretch) 4.4.107-mvebu64" on my ESPRESSObin.

When I check the cpu-frequency with armbianmonitor -m, the cpu runs always at 200MHz.

 

After the following commands:

cpufreq-set -c 0 -d 200000 -u 1200000 -g ondemand

cpufreq-set -c 1 -d 200000 -u 1200000 -g ondemand

 

the cpu runs always at 1200MHz.

After a reboot it runs at 200MHz again.

 

It looks like the cpu doesn't scale with the load.

 

kr.,

Frepke

[ebin-dev]

3 hours ago, Patrick said:

It looks like the cpu doesn't scale with the load.

 

All my best wishes to everybody too.

The file /etc/default/cpufrequtils was overwritten by default values - since you use a system with 1200MHz max frequency you need to change the values back to something like this (that was the reason why I recommended to flash u-boot with 1000MHz):

Quote

ENABLE=true
MIN_SPEED=300000
MAX_SPEED=1200000
GOVERNOR=ondemand