Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
64 bit Gentoo On Raspberry Pi 3 HOWTO
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Sat Feb 04, 2017 7:37 pm    Post subject: 64 bit Gentoo On Raspberry Pi 3 HOWTO Reply with quote

Team,

I wrote a wee ditty to smooth the way for 64 bit Gentoo on Raspberry Pi3.
Its a total rewrite of my original, which is totally out of date, even though its less than a year old.

Its not tested yet. Volunteers welcome. When I know that its mostly harmless, I'll move it to the main Wiki.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 221

PostPosted: Sun Feb 05, 2017 5:46 pm    Post subject: Reply with quote

Looks good!

Some random thoughts (in no particular order or coherence):

* In /boot/config.txt, you can specify the amount of memory to give to the CMA (memory allocator); it makes sense to provide a reasonable ceiling if you are going to use graphically heavy apps. In the image, I have:
Code:
# select hybrid VC4 mode, so we can use X and gl
# see https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README
# we use a CMA of 256MB, 256MB-aligned (needs 1GB)
# per https://github.com/anholt/mesa/issues/56#issuecomment-263341225, no
# point trying to use >256MB, RPi3's hardware does not support it
dtoverlay=vc4-fkms-v3d,cma-256
# per https://github.com/anholt/mesa/issues/56#issuecomment-263283300
# gpu_mem is for closed-source driver only; since we are only using the
# open-source driver here, set low
gpu_mem=64


* Also, the use of hdmi_drive=2, while useful for ensuring audio over HDMI works, may give sub-optimal performance / flickering on DVI monitors. Perhaps link to these docs.

* Bluetooth firmware: I think that the default bluez version of hciattach (there is an 'improved' variant out there somewhere too) actually tries to load the file /etc/firmware/BCM43430A1.hcd (yep, /etc/firmware); you can get get the firmware from here. The default hciattach may also fail, so I use the following hack in the bootable image (/etc/local.d/bluetooth.start):
Code:
#!/bin/bash

# Bluetooth is connected to /dev/ttyAMA0 so attach it and
# load the firmware (from /etc/firmware)
declare -i I
for ((I=0;I<5;I++)); do
   /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
   # process is unreliable, so retry if not successful
   if pgrep hciattach; then
      break;
   fi
done


* You mention (and indeed, originally pointed out to me!) that the bcmrpi3_defconfig defaults to the 600 MHz governor. This can be overridden at kernel build time as you point out, or you can use a script (as I do in the image, with settings copied from Raspbian, who also do it by script). Keeping the 'vanilla' bcmrpi3_defconfig settings may enable the use of pre-rolled kernel/module sets from upstream for 64-bit someday (as can be done for 32-bit now). My /etc/local.d/ondemand_freq_scaling.start is:
Code:
#!/bin/bash

# switch to on-demand frequency scaling for better performance
# (Pi's default is powersave)

echo "Switching to on-demand CPU freqency scaling..." > /dev/console
SYS_CPUFREQ_GOVERNOR=/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
if [ -e "${SYS_CPUFREQ_GOVERNOR}" ]; then
    echo "ondemand" > "${SYS_CPUFREQ_GOVERNOR}"
    echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
    echo 100000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
    echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
    echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
fi


* Another source for the RPi WiFi firmware is here.

* I have tested audio out over the headphone jack (appears to work OK).

* It is useful to get distcc/crossdev working as soon as possible when building out the Pi3 locally, as it is painfully slow otherwise. I have a short step-by-step for this on 64-bit here.

* If using vc4, it needs to be added as a VIDEO card in make.conf. It is sensible to ensure there is a framebuffer fallback too; that way you can simply comment out dtoverlay=vc4-fkms-v3d in config.txt if things go pear-shaped. The make.conf from the bootable image is:
Code:
# Simple make.conf for 64-bit Raspberry Pi 3

CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

# for use when compiling locally
MAKEOPTS="-j5 -l4"
EMERGE_DEFAULT_OPTS="--jobs=5 --load-average=4"
# for use with compiling with distcc only
#MAKEOPTS="-j32 -l4"
#EMERGE_DEFAULT_OPTS="--jobs=5 --load-average=4"

# Only free software, please.
ACCEPT_LICENSE="-* @FREE CC-Sampling-Plus-1.0"

# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable before changing.
CHOST="aarch64-unknown-linux-gnu"

# Use the 'testing' branch - otherwise we'll have to keyword everything
ACCEPT_KEYWORDS="~arm64"

# Additional USE flags in addition to those specified by the current profile.
USE="bindist -mudflap -sanitize"
USE="${USE} bluetooth egl gles1 gles2 lock thunar qt4 ffmpeg"
USE="${USE} -gnome -kde"

PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"

# per https://wiki.gentoo.org/wiki/Raspberry_Pi_VC4
VIDEO_CARDS="fbdev vc4"
INPUT_DEVICES="evdev synaptics"

# Turn on logging - see http://gentoo-en.vfose.ru/wiki/Gentoo_maintenance.
PORTAGE_ELOG_CLASSES="info warn error log qa"
PORTAGE_ELOG_SYSTEM="save"
# Logs go to /var/log/portage/elog by default - view them with elogviewer.

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C

# use (and verify) signed package snapshots, and build binary packages
# as a byproduct of each emerge (these are useful backups)
FEATURES="webrsync-gpg buildpkg"

# uncomment to disribute emerges, where possible, using distcc
FEATURES="${FEATURES} distcc distcc-pump"

# uncomment to use binary packages from PORTAGE_BINHOST, where
# available (and build normally, where not)
#FEATURES="${FEATURES} getbinpkg"
#PORTAGE_BINHOST="https://isshoni.org/pi64"

PORTAGE_GPG_DIR="/etc/portage/gpg"

GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://trumpetti.atm.tut.fi/gentoo/"


* It is useful to have "buildpkg" in place when building out, as this provides a quick backup for rollback in case of error, and only costs storage, hardly any time.

* I have not been able to get glibc to build reliably in mixed-host distcc mode, and I think you may have experienced something similar. This is a nasty problem as it can take out a emptytree system build and leave the install unbootable, so perhaps worth mentioning (I PR'd you about this one I think).

* Given the lack of hardware clock, worth mentioning swclock boot service; also an NTP client?

* Make sure you have enough inodes for your root filesystem! mkfs.ext4 -i 8182 /dev/<foo> or similar maybe?

* To prevent programs like vlc killing X, disable xv in your Xserver; in the image, I have (in /etc/X11/xorg.conf.d/50-disable-Xv.conf):
Code:
# Xv currently crashes; use gl output for video instead
Section "Extensions"
        Option      "XVideo" "Disable"
EndSection


*Up-to-date versions of the ARM firmware for /boot can be pulled from here, rather than copying from an existing Raspbian image (which may be old and therefore e.g. not support vc4-fkms-v3d properly).

If I think of anything else I will post it.

Off to try to fix my PRs now ^-^ (looks like I'll need to add package.use.mask entries for all the USE flags not tested).
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Mon Feb 06, 2017 4:12 pm    Post subject: Reply with quote

Sakaki,

Some of this I know, some is new.

My Pi3_One_Year_On guide is a get you booted guide only, rather like the handbook.
Well spotted with the i-node count on root. I didn't put the portage snapshot on during testing, and I doubt if it will fit.

Maybe I'll do an Xorg guide separately.

I'll read this over again. At the moment, testing the guide, not only will it not boot, I don't get the rainbow either, so I suspect I have the wrong sort of FAT on /boot.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Jon Wilder
Tux's lil' helper
Tux's lil' helper


Joined: 04 Apr 2011
Posts: 98
Location: Fresno CA

PostPosted: Thu Jul 13, 2017 7:49 am    Post subject: Reply with quote

My company recently contracted me to design an IoT project for them using Synapse Wireless mesh network RF radios. As the host bridge server, I felt that a Raspberry Pi would be great to run a minimalist Gentoo system on.

Following the tutorial twice for the 64-bit Pi 3 Model B, I ended up with the same result. No boot and no rainbow on power up. Using a clue from Neddy that he may have the wrong FAT type on boot, I did some research.

After partitioning the SD card and formatting the /boot partition as per the Wiki -

Code:

user@localhost ~ $ mkfs -t vfat /dev/sdb1


I ran Parted and looked at the partition table. As it turns out, mkfs was formatting it FAT16 and not FAT32 (the rpi boot code requires FAT32).

Upon further research, I came to learn that regardless of the partition type set in fdisk, mkdosfs will decide for you the bit size that it thinks is best for the FAT if it is not explicitly implied in the command line options with the -F switch. If you're lucky it will decide FAT32. In my case though, it was defaulting to FAT16.

Reformatting the partition with -

Code:

user@localhost ~ $ mkfs -t vfat -F 32 /dev/sdb1


corrected the file system on the /boot partition to FAT32.

I have completely started the install over by deleting all of the previous installation files and starting anew, but again this time I partitioned the SD card as follows -

Code:

Disk /dev/sdb: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa4f60116

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdb1  *       2048   264191   262144  128M  c W95 FAT32 (LBA)
/dev/sdb2        264192  4458495  4194304    2G 82 Linux swap / Solaris
/dev/sdb3       4458496 62333951 57875456 27.6G 83 Linux


Notice the boot partition is set for type c - W95 FAT32 (LBA). I noticed that the Wiki which covers the 32-bit install was also set to type c so I went with that instead. Then I ran mkfs -t vfat -F 32 /dev/sdb1.

A quick look at the partition table in Parted confirms that it was properly formatted FAT32 -

Code:

Model: Mass Storage Device (scsi)
Disk /dev/sdb: 31.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  135MB   134MB   primary  fat32           boot, lba
 2      135MB   2283MB  2147MB  primary  linux-swap(v1)
 3      2283MB  31.9GB  29.6GB  primary  ext4


The kernel is currently building on my host system. Once it's finished I'll be ready to boot and test.

Note: I've already edited the 64-bit Wiki with my findings explained above, and also placed an "IMPORTANT" note regarding using the -F switch when creating the vfat file system.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Thu Jul 13, 2017 8:28 am    Post subject: Reply with quote

Jon Wilder,

Thank you. I may not of noticed as my /boot is 64G.

The boot process is that the GPU loads bootcode.bin, which draws the rainbow.
bootcode.bin then checks the boot flag and I think, the partition type.
If the GPU can't load bootcode.bin, it can't draw the rainbow.
bootcode.bin runs on the GPU. The ARM CPU is held reset until the kernel, dtb and optionally, the initrd are loaded.

There is normally no connection between the partition type indicated in the partition table and the filesystem actually on the partition.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Jon Wilder
Tux's lil' helper
Tux's lil' helper


Joined: 04 Apr 2011
Posts: 98
Location: Fresno CA

PostPosted: Thu Jul 13, 2017 10:50 am    Post subject: Reply with quote

NeddySeagoon wrote:
Jon Wilder,

Thank you. I may not of noticed as my /boot is 64G.

The boot process is that the GPU loads bootcode.bin, which draws the rainbow.
bootcode.bin then checks the boot flag and I think, the partition type.
If the GPU can't load bootcode.bin, it can't draw the rainbow.
bootcode.bin runs on the GPU. The ARM CPU is held reset until the kernel, dtb and optionally, the initrd are loaded.

There is normally no connection between the partition type indicated in the partition table and the filesystem actually on the partition.


Question...if the partition type is not correct, how can the GPU load bootcode.bin which resides on the partition that is not correct?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Thu Jul 13, 2017 11:34 am    Post subject: Reply with quote

Jon Wilder,

It can't. That's why there is no rainbow when you have a FAT16 /boot.
Its not until bootcode.bin is loaded, which requires a FAT32 /boot to work, that the bootable flag and partition type are checked.
Its already too late then, you know it works, so the check is pointless.
Rather like a PC BIOS checking the bootable flag on the MSDOS partition table or the even more bizarre "No keyboard detected, Press F11 to continue"
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Mon Jul 24, 2017 8:27 pm    Post subject: Overlay source Reply with quote

Hi Neddy,

finally back on the forum after a long time moving to the new apartment.
I've started up my RPi3 and was enlightened to find your total rewrite of the installation guide. So far all is smooth.

Only question arising: In the tutorial we are using the provided overlay directory for a kernel we compile ourselves.
So the versions and configs (if they matter, I'm not into that device tree/overlay stuff) of the kernel image and the overlay may mismatch.
Could this create a problem?

I'm using the overlay directory from the kernel build and will see where I get from here, but your thoughts on that would be interesting to me.

Anyway, amazing work!
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Mon Jul 24, 2017 9:06 pm    Post subject: Reply with quote

dr_wulsen,

Welcome back. I hope you have settled in.

I didn't know there was an overlay directory in the kernel. I'll need to look more carefully.

The device tree binary and its overlays, in /boot/overlays describe the hardware to the kernel.
Saying that its kernel version independent is the ideal but as a whole, the device tree stuff only changes when new hardware comes along.
That's true for the Foundation kernels but not for mainline, where Raspberry Pi support is incomplete.

You can reasonably safely mix and match device trees in Foundation kernels but because of the pace of development, not with mainline kernels
Both kernels use different names for the device tree files.

Overlays are the same. A device tree overlay describes how to set up the Pi and which kernel modules to load for a given device.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Mon Jul 24, 2017 9:43 pm    Post subject: Reply with quote

Thanks Neddy,

now it's clear to me, thank you!

I guess that in the overlay directory, there is the device tree source (*.dts) files, which would need to be compiled into device tree binary objects (*.dtbo) files before being able to use them.
Found a program in the portage repository, sys-apps/dtc. I'll try it out to get *.dtbo from that thing and see if I can give back a little bit.
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Mon Jul 24, 2017 9:45 pm    Post subject: Reply with quote

dr_wulsen,

There is a dtc free with the kernel too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Mon Jul 24, 2017 9:48 pm    Post subject: Reply with quote

neddy, thanks again.

actually it should have been natural to check the kernel first for a dtc compiler.
I'll give it a shot and see if my hardware works (I need the hifiberry-digi+ overlay anyway to get my TOSLINK work).

Once tested, I'll come back.
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
MasterGollom
n00b
n00b


Joined: 23 May 2016
Posts: 10
Location: Luxembourg

PostPosted: Sat Jul 29, 2017 10:18 am    Post subject: Reply with quote

Hi,

I'm trying to build a kernel for my rapsberry pi 3 using the tutorial but I'm having troubles with crossdev.

Maybe someone can help me out.

Code:
crossdev -t aarch64-unknown-linux-gnu --ov-output /usr/local/portage/


gives me the following error:

Code:
root@gentoo-testvm ~ # crossdev -t aarch64-unknown-linux-gnu --ov-output /usr/local/portage/
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 * crossdev version:      20151026
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   arm64
 * Target System:         aarch64-unknown-linux-gnu
 * Stage:                 4 (C/C++ compiler)
 * ABIs:                  arm64

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               linux-headers-[latest]
 * libc:                  glibc-[latest]

 * CROSSDEV_OVERLAY:      /usr/local/portage/
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:
 * Portage flags:
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  - 
 * leaving sys-devel/binutils in /usr/local/portage/
 * leaving sys-devel/gcc in /usr/local/portage/
 * leaving sys-kernel/linux-headers in /usr/local/portage/
 * leaving sys-libs/glibc in /usr/local/portage/
 * leaving sys-devel/gdb in /usr/local/portage/
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _ -
 * Log: /var/log/portage/cross-aarch64-unknown-linux-gnu-binutils.log
 * Emerging cross-binutils ...

 * binutils failed :(
 *
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-aarch64-unknown-linux-gnu-info.log
 * /var/log/portage/cross-aarch64-unknown-linux-gnu-binutils.log.xz
 * /var/tmp/portage/cross-aarch64-unknown-linux-gnu/binutils*/temp/binutils-config.logs.tar.xz


Here's the /var/log/portage/cross-aarch64-unknown-linux-gnu-info.log

Code:
root@gentoo-testvm ~ # cat /var/log/portage/cross-aarch64-unknown-linux-gnu-info.log
------------------------------------------------------------------------------------------------------------------------------------------------------------
 * crossdev version:      20151026
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   arm64
 * Target System:         aarch64-unknown-linux-gnu
 * Stage:                 4 (C/C++ compiler)
 * ABIs:                  arm64

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               linux-headers-[latest]
 * libc:                  glibc-[latest]

 * CROSSDEV_OVERLAY:      /usr/local/portage/
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:
 * Portage flags:
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
Portage 2.3.6 (python 3.4.5-final-0, default/linux/amd64/13.0, gcc-5.4.0, glibc-2.23-r4, 4.9.34-gentoo x86_64)
=================================================================
System uname: Linux-4.9.34-gentoo-x86_64-AMD_FX-tm-8150_Eight-Core_Processor-with-gentoo-2.3
KiB Mem:     3976228 total,   3641624 free
KiB Swap:     524284 total,    524284 free
Timestamp of repository gentoo: Fri, 28 Jul 2017 19:30:01 +0000
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.28 p1.2) 2.28
app-shells/bash:          4.3_p48-r1::gentoo
dev-lang/perl:            5.24.1-r2::gentoo
dev-lang/python:          2.7.12::gentoo, 3.4.5::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.3::gentoo
sys-apps/openrc:          0.26.3::gentoo
sys-apps/sandbox:         2.10-r3::gentoo
sys-devel/autoconf:       2.69::gentoo
sys-devel/automake:       1.15-r2::gentoo
sys-devel/binutils:       2.28-r2::gentoo
sys-devel/gcc:            5.4.0-r3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:           2.23-r4::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

ABI="amd64"
ABI_X86="64"
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
ACCEPT_PROPERTIES="*"
ACCEPT_RESTRICT="*"
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias"
ARCH="amd64"
AUTOCLEAN="yes"
BOOTSTRAP_USE="cxx unicode internal-glib python_targets_python3_4 python_targets_python2_7 multilib"
CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CFLAGS_amd64="-m64"
CFLAGS_x32="-mx32"
CFLAGS_x86="-m32"
CHOST="x86_64-pc-linux-gnu"
CHOST_amd64="x86_64-pc-linux-gnu"
CHOST_x32="x86_64-pc-linux-gnux32"
CHOST_x86="i686-pc-linux-gnu"
CLEAN_DELAY="5"
COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"
COLLISION_IGNORE="/lib/modules/* *.py[co] *$py.class */dropin.cache"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo"
CONSOLETYPE="pty"
CPU_FLAGS_X86="mmx sse sse2"
CXXFLAGS="-march=native -O2 -pipe"
DEFAULT_ABI="amd64"
DISTDIR="/usr/portage/distfiles"
EDITOR="/bin/nano"
ELIBC="glibc"
EMERGE_WARNING_DELAY="10"
EPREFIX=""
EROOT="/"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync
xattr"
FETCHCOMMAND="wget -t 3 -T 60 --passive-ftp -O "${DISTDIR}/${FILE}" "${URI}""
FETCHCOMMAND_RSYNC="rsync -avP "${URI}" "${DISTDIR}/${FILE}""
FETCHCOMMAND_SFTP="bash -c "x=\${2#sftp://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; eval \"declare -a ssh_opts=(\${3})\" ; exec sftp \${port:+-P \${port}} \"\${ssh_opts[@]}\" \"\${host}:/\${x#*/}\" \"\$1\"" sftp "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""
FETCHCOMMAND_SSH="bash -c "x=\${2#ssh://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; exec rsync --rsh=\"ssh \${port:+-p\${port}} \${3}\" -avP \"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""
FFLAGS="-O2 -pipe"
GCC_SPECS=""
GENTOO_MIRRORS="http://distfiles.gentoo.org"
GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx"
GRUB_PLATFORMS=""
HOME="/root"
INFOPATH="/usr/share/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.28/info"
INPUT_DEVICES="libinput keyboard mouse"
IUSE_IMPLICIT="abi_x86_64 prefix prefix-chain prefix-guest"
KERNEL="linux"
LANG="en_US.utf8"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text"
LC_MESSAGES="C"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LDFLAGS_amd64="-m elf_x86_64"
LDFLAGS_x32="-m elf32_x86_64"
LDFLAGS_x86="-m elf_i386"
LESS="-R -M --shift 5"
LESSOPEN="|lesspipe %s"
LIBDIR_amd64="lib64"
LIBDIR_x32="libx32"
LIBDIR_x86="lib32"
LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer"
LOGNAME="root"
MAIL="/var/mail/root"
MAKEOPTS="-j2"
MANPAGER="manpager"
MANPATH="/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.28/man"
MULTILIB_ABIS="amd64 x86"
MULTILIB_STRICT_DENY="64-bit.*shared object"
MULTILIB_STRICT_DIRS="/lib32 /lib /usr/lib32 /usr/lib /usr/kde/*/lib32 /usr/kde/*/lib /usr/qt/*/lib32 /usr/qt/*/lib /usr/X11R6/lib32 /usr/X11R6/lib"
MULTILIB_STRICT_EXEMPT="(perl5|gcc|gcc-lib|binutils|eclipse-3|debug|portage|udev|systemd|clang|python-exec|llvm)"
MULTIOSDIRS="../lib64:../lib32"
NETBEANS="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml"
NOCOLOR="true"
OFFICE_IMPLEMENTATION="libreoffice"
OLDPWD="/root"
PAGER="/usr/bin/less"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0"
PHP_TARGETS="php5-6"
PKGDIR="/usr/portage/packages"
PORTAGE_ARCHLIST="alpha amd64 amd64-fbsd amd64-linux arm arm-linux arm64 arm64-linux hppa ia64 m68k m68k-mint mips nios2 ppc ppc-aix ppc-macos ppc64 ppc64-linux riscv s390 sh sparc sparc-fbsd sparc-solaris sparc64-solaris x64-cygwin x64-macos x64-solaris x86 x86-cygwin x86-fbsd x86-linux x86-macos x86-solaris x86-winnt"
PORTAGE_BIN_PATH="/usr/lib/portage/python3.4"
PORTAGE_COMPRESS_EXCLUDE_SUFFIXES="css gif htm[l]? jp[e]?g js pdf png"
PORTAGE_CONFIGROOT="/"
PORTAGE_DEBUG="0"
PORTAGE_DEPCACHEDIR="/var/cache/edb/dep"
PORTAGE_ELOG_CLASSES="log warn error"
PORTAGE_ELOG_MAILFROM="portage@localhost"
PORTAGE_ELOG_MAILSUBJECT="[portage] ebuild log for ${PACKAGE} on ${HOST}"
PORTAGE_ELOG_MAILURI="root"
PORTAGE_ELOG_SYSTEM="save_summary:log,warn,error,qa echo"
PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS="5"
PORTAGE_FETCH_RESUME_MIN_SIZE="350K"
PORTAGE_GID="250"
PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign --yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}" "${FILE}""
PORTAGE_INST_GID="0"
PORTAGE_INST_UID="0"
PORTAGE_INTERNAL_CALLER="1"
PORTAGE_OVERRIDE_EPREFIX=""
PORTAGE_PYM_PATH="/usr/lib64/python3.4/site-packages"
PORTAGE_PYTHONPATH="/usr/lib64/python3.4/site-packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_RSYNC_RETRIES="-1"
PORTAGE_SYNC_STALE="30"
PORTAGE_TMPDIR="/var/tmp"
PORTAGE_VERBOSE="1"
PORTAGE_WORKDIR_MODE="0700"
PORTAGE_XATTR_EXCLUDE="btrfs.* security.evm security.ima        security.selinux system.nfs4_acl"
PORT_LOGDIR_CLEAN="find "${PORT_LOGDIR}" -type f ! -name "summary.log*" -mtime +7 -delete"
POSTGRES_TARGETS="postgres9_5"
PROFILE_ONLY_VARIABLES="ARCH ELIBC IUSE_IMPLICIT KERNEL USERLAND USE_EXPAND_IMPLICIT USE_EXPAND_UNPREFIXED USE_EXPAND_VALUES_ARCH USE_EXPAND_VALUES_ELIBC USE_EXPAND_VALUES_KERNEL USE_EXPAND_VALUES_USERLAND"
PWD="/"
PYTHONDONTWRITEBYTECODE="1"
PYTHON_SINGLE_TARGET="python3_4"
PYTHON_TARGETS="python2_7 python3_4"
RESUMECOMMAND="wget -c -t 3 -T 60 --passive-ftp -O "${DISTDIR}/${FILE}" "${URI}""
RESUMECOMMAND_RSYNC="rsync -avP "${URI}" "${DISTDIR}/${FILE}""
RESUMECOMMAND_SSH="bash -c "x=\${2#ssh://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; exec rsync --rsh=\"ssh \${port:+-p\${port}} \${3}\" -avP \"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""
ROOT="/"
ROOTPATH="/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0"
RPMDIR="/usr/portage/rpm"
RUBY_TARGETS="ruby21 ruby22"
SHELL="/bin/bash"
SHLVL="2"
SSH_CLIENT="192.168.1.10 37671 22"
SSH_CONNECTION="192.168.1.10 37671 192.168.1.251 22"
SSH_TTY="/dev/pts/0"
SYMLINK_LIB="yes"
TERM="vt220"
TWISTED_DISABLE_WRITING_OF_PLUGIN_CACHE="1"
UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"
USE="acl amd64 berkdb bindis bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 modules multilib ncurses nls nptl openmp pam pcre readline seccomp session ssl tcpd unicode xattr zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby21 ruby22" USERLAND="GNU" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
USER="root"
USERLAND="GNU"
USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_EXPERIMENTAL_FEATURES CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_X86 CROSSCOMPILE_OPTS CURL_SSL ELIBC ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS LIRC_DEVICES LLVM_TARGETS MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS"
USE_EXPAND_HIDDEN="ABI_MIPS ABI_PPC ABI_S390 CPU_FLAGS_ARM CROSSCOMPILE_OPTS ELIBC KERNEL USERLAND"
USE_EXPAND_IMPLICIT="ARCH ELIBC KERNEL USERLAND"
USE_EXPAND_UNPREFIXED="ARCH"
USE_EXPAND_VALUES_ARCH="alpha amd64 amd64-fbsd amd64-linux arm arm-linux arm64 hppa ia64 m68k m68k-mint mips nios2 ppc ppc64 ppc64-linux ppc-aix ppc-macos riscv s390 sh sparc sparc64-solaris sparc-fbsd sparc-solaris x64-cygwin x64-macos x64-solaris x86 x86-cygwin x86-fbsd x86-linux x86-macos x86-solaris x86-winnt"
USE_EXPAND_VALUES_ELIBC="AIX bionic Cygwin Darwin DragonFly FreeBSD glibc HPUX Interix mingw mintlib musl NetBSD OpenBSD SunOS uclibc Winnt"
USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint HPUX linux NetBSD OpenBSD SunOS Winnt"
USE_EXPAND_VALUES_USERLAND="BSD GNU"
USE_ORDER="env:pkg:conf:defaults:pkginternal:repo:env.d"
VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy v4l"
XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"


And the /var/log/portage/cross-aarch64-unknown-linux-gnu-binutils.log

Code:

root@gentoo-testvm ~ # cat /var/log/portage/cross-aarch64-unknown-linux-gnu-binutils.log
Calculating dependencies
 * IMPORTANT: 10 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

... done!

emerge: there are no ebuilds to satisfy "cross-aarch64-unknown-linux-gnu/binutils".

emerge: searching for similar names... nothing similar found.


Can someone tell me what's wrong? :cry:

Shortened separator lines so line wraps work in cod tags -- NeddySeagoon
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Sat Jul 29, 2017 10:52 am    Post subject: Reply with quote

MasterGollom,

It appears you have told crossdev to use the overlay in /usr/local/portage/ but not configured portage to use the overlay.
Crossdev downloads the ebuilds to /usr/local/portage then emerge can't find them.

You need to tell portage about your overlay

Your overlay should be listed in
Code:
emerge --info
at this point.
Code:
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
MasterGollom
n00b
n00b


Joined: 23 May 2016
Posts: 10
Location: Luxembourg

PostPosted: Sat Jul 29, 2017 3:28 pm    Post subject: Reply with quote

NeddySeagoon,

It worked, thx :)
Back to top
View user's profile Send private message
MasterGollom
n00b
n00b


Joined: 23 May 2016
Posts: 10
Location: Luxembourg

PostPosted: Mon Jul 31, 2017 6:28 pm    Post subject: Reply with quote

Hi NeddySeagoon,

No I got gentoo up and running, but I cann't use my usb keyboard...

Here's a screenshot of what it shows me on boot:
http://abload.de/image.php?img=20542894_1015542007177vsdm.png

any ideas? I hope the usb controller isn't dead since no port is working :cry:

EDIT: tried an SD Card with Raspian on it...the keyboard works on this distro...
EDIT: rpi-4.13.y doesn't work...rpi-4.10.y does
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Sun Aug 06, 2017 1:58 pm    Post subject: Reply with quote

@Master Gollom:

I've had exactly the same.
That was when I was using kernel 4.12 or 4.13, don't remember exactly.

If you get the sources for 4.9y (others may work, but I only tested 4.9) and make the bcmrpi3_defconfig, you will be back on track.

Code:
git clone --single-branch --branch=rpi-4.9.y https://github.com/raspberrypi/linux.git
should give you the sources that work.
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Sun Aug 06, 2017 2:09 pm    Post subject: Reply with quote

@Master Gollom,

As dr_wulsen says, the 4.9.y foundation kernel gets patches first.
The bcmrpi3_defconfig runs your Pi at 600MHz. You may want to change the default governor to On Demand.
Be careful what you prune too. There is a lot of junk there but make a kernel that works first, prune it later.
The USB on the Pi needs the dwc2 driver. Only host mode is usable on the Pi, even though the port on the Broadcom CPU is OTG capable.
Its wired to the USB 4 port and Ethernet chip, so OTG does not reach the outside world.

The mainline kernel is worth a try from time to time. Its getting better but as of 4.12, not ready yet.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Wed Aug 16, 2017 9:54 am    Post subject: Devicetree objects Reply with quote

@Neddy
I've tried the *.dtbo files created under arch/arm/boot/dts/overlays/ and found them to be usable.
A simple make all has created .dtbo files for me and they are working.

With the created files, I can fire up my hifiberry-digi board using the overlay file.

But what I'm gonna need now is to write a script that puts all the files where they belong after cross-compiling the kernel on my desktop finishes.

By the way, I've found some sweet improvement (which I have not benchmarked and don't have any proof of) which made my kernel (bootup, overall smoothness) feel faster.
Appending
Code:
KBUILD_CFLAGS   += -march=armv8-a+crc
KBUILD_CFLAGS   += -mtune=cortex-a53
KBUILD_CFLAGS   += -ftree-vectorize
to arch/arm64/Makefile, I placed it in an unconditional section (here):
Code:
KBUILD_CFLAGS   += -mgeneral-regs-only $(lseinstr)
KBUILD_CFLAGS   += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS   += $(call cc-option, -mpc-relative-literal-loads)
KBUILD_AFLAGS   += $(lseinstr)
KBUILD_CFLAGS   += -march=armv8-a+crc
KBUILD_CFLAGS   += -mtune=cortex-a53
KBUILD_CFLAGS   += -ftree-vectorize
and verfied that GCC was using it. The produced kernel feels much more smooth and bootup faster, but as said: no proof for anything.
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 221

PostPosted: Wed Aug 16, 2017 8:39 pm    Post subject: Re: Devicetree objects Reply with quote

dr_wulsen wrote:
By the way, I've found some sweet improvement (which I have not benchmarked and don't have any proof of) which made my kernel (bootup, overall smoothness) feel faster.
Appending
Code:
KBUILD_CFLAGS   += -march=armv8-a+crc
KBUILD_CFLAGS   += -mtune=cortex-a53
KBUILD_CFLAGS   += -ftree-vectorize
to arch/arm64/Makefile, I placed it in an unconditional section (here):
Code:
KBUILD_CFLAGS   += -mgeneral-regs-only $(lseinstr)
KBUILD_CFLAGS   += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS   += $(call cc-option, -mpc-relative-literal-loads)
KBUILD_AFLAGS   += $(lseinstr)
KBUILD_CFLAGS   += -march=armv8-a+crc
KBUILD_CFLAGS   += -mtune=cortex-a53
KBUILD_CFLAGS   += -ftree-vectorize
and verfied that GCC was using it. The produced kernel feels much more smooth and bootup faster, but as said: no proof for anything.

That's very interesting! Are there any issues with optimizing the kernel build in this way? If not, I will add these settings to my weekly-autobuilld bcmrpi3-kernel.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Thu Aug 17, 2017 6:37 am    Post subject: Reply with quote

@Sakaki: Up to now I haven't encountered any issue, I have been doing some compiling (kodi) and tonight will try 1080p video playback with 5.1 optical audio output (unfortunately i have to patch kodi for that, because the hifiberry doesn't register itself as IEC958 interface due to a bug in the kernel driver).

But before patching your wonderful Image with that, I think we could do some testing - do you have a plan how to test kernel performance?

Ah, BTW: There's another speedup that's low-hanging fruit: Overclocking the Micro SD. Runs on 50MHz by default, any UHS card is capable of 100MHz. Can be done by config. txt and Improves big file operations a lot, 4k random writes by approx. 20%.
https://www.jeffgeerling.com/blog/2016/how-overclock-microsd-card-reader-on-raspberry-pi-3 From another site, I've read to append boot_delay=1 to avoid sd corruption when overclocking the ARM/GPU, so I've added that too. Runs like a charm, but will make your Image unusable on any cards that are not UHS....

Looking forward to your ideas on Kernel performance testing!
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 221

PostPosted: Thu Aug 17, 2017 9:30 am    Post subject: Reply with quote

dr_wulsen,

most obvious would be to try something like sysbench; just tried to emerge that with ACCEPT_KEYWORDS="* ~*", but one of its dependencies, dev-lang/luajit, doesn't support arm64 in any of the versions covered by the available in-tree ebuilds. However, luajit-2.1.0-beta3 does now support arm64, so I may try putting an ebuild for that in my rpi3-overlay repo. If sysbench builds it would be possible to try headless tests with the only difference being the optimized / non-optimized kernel.

The other thing would be to run Roy Longbottom's benchmarks with the optimized kernel. They aren't really designed to test kernel features per se, but it is has always bothered me that the Suse 64-bit benchmarks had a slight edge on Gentoo (particularly since the entire userland was compiled to match the RPi3 SoC explicitly). But an optimized kernel could easily explain the difference.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
dr_wulsen
n00b
n00b


Joined: 21 Aug 2013
Posts: 66
Location: Beautiful Austria, Lake area in Upper Austria

PostPosted: Thu Aug 17, 2017 8:28 pm    Post subject: Reply with quote

@Sakaki: Thank you for your info and explanations, once I've got this thing to its main use (Kodi player) I will try (after a backup).

However, if anyone has an idea how to get the stuff I'm trying to achieve up and running, I'd be most grateful.

Got Kodi-18.0-alpha-1 (kodi-9999) running with the vc4-fkms-v3d driver; gpu_mem is set to 16 (but 128 makes no difference).
system ic OC'd to
Code:
# overclock
arm_freq=1300
core_freq=500
sdram_freq=500
over_voltage=2
initial_turbo=60
# prevent sd corruption on overclock
boot_delay=1

# sd "overclock"
dtoverlay=sdhost,overclock_50=100
and running stable.
Kodi starts and is stable, it updates a library with a few ten thousand songs and adds my movies, which is fine.

Now if I want to play a movie (1080p, ~10G filesize, 5.1 Audio direct passthrough optical) it does play and it does so stable.
But it does not do so well. It uses up 100% of all four cores and says the codec used is ff-h264 (SW)

Far as I can guess, the RPi is capable of decoding h264 in hardware. But that's not what I get here...
Kodi tells me about the graphics:
Code:
GPU: VC4 V3D 2.1
OpenGL-Vendor: Broadcom
OpenGL-Version: 2.1 Mesa17.2.0-rc4


Mesa 17.2.0_rc4 useflags are
Code:
(dri3 egl gallium gbm gles2 nptl -bindist -classic -d3d9 -debug -gles1 -llvm -opencl -openmax -osmesa -pax_kernel -pic -selinux -unwind -vaapi -valgrind -vdpau -vulkan -wayland -xa -xvmc ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="-32 -64 -x32" VIDEO_CARDS="vc4 -freedreno -i915 -i965 -imx -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vivante -vmware")
and kodi is installed with
Code:
(X alsa css gles nfs opengl system-ffmpeg udev webserver xslt -airplay -bluetooth -bluray -caps -cec -dbus -debug -dvd -libressl -libusb -lirc -mysql -pulseaudio -samba -sftp -systemd -test -udisks -upnp -upower -vaapi -vdpau -zeroconf PYTHON_TARGETS="python2_7")

And if I run unsynchronized glxgears, I get approx. 780fps. But no hardware video decoding.

Compiling raspberrypi-userland-9999 fails at the assembler part, which I didn't mess with changing the -march, and now I'm stuck with my media center that doesn't play 1080p too well.
raspberrypi-userland-bin installs, but nothing seems to use those libraries when starting without the fkms driver either.

Any ideas will be rewarded with a beer, shall we meet.
_________________
There's no stupid questions, only stupid answers.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41417
Location: 56N 3W

PostPosted: Fri Aug 18, 2017 12:04 am    Post subject: Reply with quote

dr_wulsen,

Quote:
Got Kodi-18.0-alpha-1 (kodi-9999) running with the vc4-fkms-v3d driver; gpu_mem is set to 16 (but 128 makes no difference).


The two video drivers use different memory allocation mechanisms.
gpu_mem reserver a fixed amount af RAM for the old video driver. This is mostly wasted RAM if you use the vc4 driver.
However, the vc4 does things other than video, so gpu_mem=16 is the lowest you can set.

The vc4 does have some hardware video decoding capability. At least some of it needs a licence that's locked to the Pi serial number.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 221

PostPosted: Fri Aug 18, 2017 11:09 am    Post subject: Reply with quote

According to this kodi FAQ, there are two h/w video decoding mechanisms that kodi will try to use on the RPi3:
  • MMAL and
  • OpenMAX IL (referred to as "omxplayer" in the kodi docs)
MMAL stands for Multi-Media Abstraction Layer. There are some details about it here. It is a proprietary Broadcom API.
OpenMAX IL stands for Open Media Acceleration, Integration Layer. There are some details about it here. It is an open standard.

Unfortunately, by default, the current VC4 open-source driver exposes neither MMAL nor OpenMAX IL. What it does do is give you a fast gl-based pipe to blit userland-rendered stuff for display (plus GPU-rendered gl stuff of course, for glamor shading, 3D games, glxgears(!) etc.). This is better than nothing, but in an ideal world we'd be able to use the Pi's h/w decoding directly.

raspberrypi-userland should give you access to these components. Unfortunately, the last in-tree ebuild (0_pre20160424, or even the 9999) won't build on arm64. I have a patched ebuild (use at own risk) for the 9999 raspberrypi-userland here, it just sets DARM64=on. This lets you use most of the userland utils (so you can query the videocore temperature, things like that), but unfortunately, looking at the upstream CMakeLists.txt, we see:
Code:
if(ARM64)
   set(BUILD_MMAL FALSE)
   set(BUILD_MMAL_APPS FALSE)
else()
   set(BUILD_MMAL TRUE)
   set(BUILD_MMAL_APPS TRUE)
endif()

That rules out MMAL. It then goes on:
Code:
if(NOT ARM64)
   add_subdirectory(middleware/openmaxil)
endif()
so direct access to the OpenMAX IL layer is also purged (the underlying issue in both cases has to do with 32-bit vs 64-bit pointers, ironic given the size of the Pi3's memory, but AFAIK hasn't yet been patched).

Please double check what I have written here as I haven't looked at it for quite a while. But I think the bottom line is that full h/w video decode isn't going to work in 64-bit mode, until someone fixes the kernel pointer issue.

PS NeddySeagoon is also correct, there are some codecs for which you need to buy a license, and put a key in /boot/config.txt. H.264 is included in the price of the RPi3, but not MPEG-2 (DVDs) or VC-1 (WMV), so even if you had MMAL or OpenMAX access, you'd need a license to h/w decode either of those two (viz, MPEG-2 or VC-1) formats. In theory, the RPi3 can decode 1080p MPEG-2 in software, but it's on the edge of what it can do.

BTW your glxgears score looks a little low. Do you have compositing or similar turned on on your desktop?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum