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

  • 0
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 ?

Link to comment
Share on other sites

Donate and support the project!

  • 0

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.  

Link to comment
Share on other sites

  • 0

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

  • 0

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 

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0
18 minutes ago, Patrick said:

 

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

Link to comment
Share on other sites

  • 0
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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 0
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

 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0
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

 

Link to comment
Share on other sites

  • 0
On 2-1-2018 at 7:13 PM, ebin-dev said:

 

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

 

Thanks ebin-dev,

 

My cpufrequtils are:

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

 

The scaling doesn't work for me.

 

In the passed I tested with the 1000MHz u-boot but got a lot of kernel-panics.

Now, a few weeks or more later, I'll flash my u-boot again to 1000MHz. See what's happen.

 

 

kr.,

Patrick

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