Page 3 of 4
Re: Crossdev for RPi
Posted: Sat Apr 09, 2016 4:09 pm
by steveL
dr_wulsen wrote:I've tried an armv8-hardfloat-linux-gnueabi. don't do it, the /proc/cpuinfo gives (falsely) an armv7.
all python packages would look for a armv7 gcc and fail to build....
Answered above:
schorsch_76 wrote:If you want to compile for 64 bit, use: aarch64-unknown-linux-gnu
This was recommended on the gcc bugzilla and [post=7900188]verified by Neddy[/post] in the [topic=1041352]Raspi3 64 Bit thread[/topic].
Posted: Sat Apr 09, 2016 4:28 pm
by NeddySeagoon
dr_wulsen,
The Pi3 reports itself as arm7 in 32 bit mode and
Code: Select all
Pi3 64bit ~ # cat /proc/cpuinfo
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
in 64 bit mode.
Re: Re: Getting it up on the RPi3 - WiFi
Posted: Mon Apr 11, 2016 11:36 am
by dr_wulsen
Hi das_morph,
sorry for linking the wrong file. Obviously I got a little tired when writing the post, as my kernel would work flawless.
However, thank you for pointing it out, original post has been edited so I won't misguide others.

Posted: Wed Apr 13, 2016 10:30 pm
by keet
According to
the Mesa site, the current Mesa, as well as Linux kernel 4.5 (and the Raspberry Pi Foundation's tree of 4.1) includes support for VC4. Hopefully this will mean less trouble building packages that depend on Mesa and more ease building and running programs that use or depend on hardware video acceleration.[/url]
Posted: Thu Apr 14, 2016 6:45 am
by Yamakuzure
keet wrote:According to
the Mesa site, the current Mesa, as well as Linux kernel 4.5 (and the Raspberry Pi Foundation's tree of 4.1) includes support for VC4. Hopefully this will mean less trouble building packages that depend on Mesa and more ease building and running programs that use or depend on hardware video acceleration.[/url]
I have a mesa-9999 ebuild in my overlay (seden) that allows you to build with VIDEO_CARDS="vc4".
I am still testing and report my progress in
this thread.
Posted: Fri Apr 15, 2016 4:49 pm
by keet
After building mesa with video_cards="vc4", when I try to start a game using retroarch (inside emulationstation), it shows this error:
Code: Select all
retroarch: symbol lookup error: /usr/lib/opengl/raspberrypi-userland/lib/libOpenVG.so: undefined symbol: client_process_state
I am not sure how to fix this; I'll troubleshoot later when I have time. Does anyone here already know the fix?
Posted: Fri Apr 29, 2016 2:36 am
by vastchen
somebody know Pi3 how to config /etc/portage/make.conf
Pi 2 CFLAGS="-02 -pipe -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard "
can use this ??? Pi 3 CFLAGS="-02 -pipe -march=armv8-a -mfpu=vfpv3 -mfloat-abi=hard " ??
-march= -mtune=cortex-a53 ?????
somebody can put you pi3 /etc/portage/make.conf to see?
Posted: Fri Apr 29, 2016 2:56 am
by vastchen
vastchen wrote:somebody know Pi3 how to config /etc/portage/make.conf
Pi 2 CFLAGS="-02 -pipe -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard "
can use this ??? Pi 3 CFLAGS="-02 -pipe -march=armv8-a -mfpu=vfpv3 -mfloat-abi=hard " ??
-march= -mtune=cortex-a53 ?????
somebody can put you pi3 /etc/portage/make.conf to see?
I found somebody use armv7 somebody use armv8 what should be use ? I will crazzy , if i want pi2 distccd with pi 3 use crossdev -t “?”
Posted: Sat Apr 30, 2016 9:15 pm
by keet
vastchen wrote: I found somebody use armv7 somebody use armv8 what should be use ? I will crazzy , if i want pi2 distccd with pi 3 use crossdev -t “?”
I have been using this with no apparent problems:
Code: Select all
CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -O2 -pipe"
Posted: Tue May 03, 2016 3:33 am
by vastchen
keet wrote:vastchen wrote: I found somebody use armv7 somebody use armv8 what should be use ? I will crazzy , if i want pi2 distccd with pi 3 use crossdev -t “?”
I have been using this with no apparent problems:
Code: Select all
CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -O2 -pipe"
thanks for you help

. I got it.
Re: Getting it up on the RPi3 - WiFi
Posted: Fri May 06, 2016 7:03 pm
by safeness
dr_wulsen wrote:das_morph wrote:dr_wulsen wrote:
If anyone is interested in my custom .config for the raspberrypi-sources-4.4 to have a starting point for their own kernel, let me know - I will then post them here.
I'd be interested, since I can't seem to get the wifi to work on my pi. Might be missing some kernel modules or something. Which sources are you using for the 4.4 kernel? I tried the raspberrypi-sources package, but neither using crossdev nor native compiling with distcc resulted in a working kernel. The github sources work for me.
Hi das_morph,
I'm using the raspberrypi-sources-4.4.9999 in the portage tree, which actually downloads the github sources.
One thing I've stumbled across was that the simple zImage wouldn't work for me, if just renamed to kernel7.img, but had to use the include mkknlimg.
That's my kernel compile script:
Code: Select all
#!/bin/bash
ARCH=arm CROSS_COMPILE="/usr/bin/armv7a-hardfloat-linux-gnueabi-" make -j5 zImage modules dtbs
mkdir /tmp/rpi3
mkdir /tmp/rpi3/overlays
./scripts/mkknlimg arch/arm/boot/zImage /tmp/rpi3/kernel7.img
cp ./arch/arm/boot/dts/*.dtb /tmp/rpi3
cp ./arch/arm/boot/dts/overlays/*.dtb* /tmp/rpi3/overlays
cp ./arch/arm/boot/dts/overlays/README /tmp/rpi3/overlays
cp .config /tmp/rpi3/kernelconfig
I have sent the config to you via PN.
Of course, you will need the two files named in my earlier post.
@dr_wulsen: Can you send me your config as well?
Thanks!
Re: Getting it up on the RPi3 - WiFi
Posted: Sun May 15, 2016 4:38 pm
by dr_wulsen
safeness wrote:dr_wulsen wrote:das_morph wrote:dr_wulsen wrote:
If anyone is interested in my custom .config for the raspberrypi-sources-4.4 to have a starting point for their own kernel, let me know - I will then post them here.
I'd be interested, since I can't seem to get the wifi to work on my pi. Might be missing some kernel modules or something. Which sources are you using for the 4.4 kernel? I tried the raspberrypi-sources package, but neither using crossdev nor native compiling with distcc resulted in a working kernel. The github sources work for me.
Hi das_morph,
I'm using the raspberrypi-sources-4.4.9999 in the portage tree, which actually downloads the github sources.
One thing I've stumbled across was that the simple zImage wouldn't work for me, if just renamed to kernel7.img, but had to use the include mkknlimg.
That's my kernel compile script:
Code: Select all
#!/bin/bash
ARCH=arm CROSS_COMPILE="/usr/bin/armv7a-hardfloat-linux-gnueabi-" make -j5 zImage modules dtbs
mkdir /tmp/rpi3
mkdir /tmp/rpi3/overlays
./scripts/mkknlimg arch/arm/boot/zImage /tmp/rpi3/kernel7.img
cp ./arch/arm/boot/dts/*.dtb /tmp/rpi3
cp ./arch/arm/boot/dts/overlays/*.dtb* /tmp/rpi3/overlays
cp ./arch/arm/boot/dts/overlays/README /tmp/rpi3/overlays
cp .config /tmp/rpi3/kernelconfig
I have sent the config to you via PN.
Of course, you will need the two files named in my earlier post.
@dr_wulsen: Can you send me your config as well?
Thanks!
Hey safeness, sorry for being lazy recently, just read your post today. I've sent the config to you via PN.
Have fun

Posted: Sun May 22, 2016 7:32 am
by dr_wulsen
NeddySeagoon wrote:dr_wulsen,
That kernel emulation option generates code to deal with the illegal instruction exceptions programs built with SWP/SWPB instructs may generate when running on a CPU that is missing SWP/SWPB. Rather like the kernel software floating point option for 386/486SX CPUs that had no hardware floating point.
This is slow and horrible as there will be a user space to kernel space context switch when the illegal instruction exception is raised. The kernel will emulate the instruction, then there will be a kernel space to user space context switch back to the program to the instruction following the illegal instruction. Execution in userspace continues as if nothing had happened.
Consider the effect of this when a SWP is used in a loop ...
The problem here is
Code: Select all
{standard input}:134: Error: swp{b} use is obsoleted for ARMv8 and later
that gcc is generating these instructions and passing them to the assembler, which then objects.
There may be a gcc/assembler option (CFLAG) to allow these instructions to be compiled. If so, and this works, you will need that kernel option if SWP/SWPB is not implemented in the Pi 3 CPU.
Neddy,
I just got thinking...the SWP/SWPB is required in the RPi3 kernel.
Cause when compiling sys-libs/db with the ARMv8 arch, the linker will (as you explained perfectly clear, thank you) complain about the SWP/SWPB being unsupported on this arch.
But if we now compile it with an ARMv7 march, it will generate the SWP/SWPB code as well - only the linker is not going to complain, as it was supported on an ARMv7.
So actually, what should happen is the context switches you have predicted.
Do you know of any testing method I could use to have sys-libs/db do actual work - so I should be able to see the context switching happening frequently (and too often) by usage of vmstat?
Thanks!
Posted: Sun May 22, 2016 9:56 am
by NeddySeagoon
dr_wulsen,
The Pi CPU can operate in either 32 bit or 64 bit mode. Its even possible to switch from 64 bit mode to 32 bit mode and back again.
In 32 bit mode, the Pi is a arm7 CPU - complete with all the instructions that are obsolete on arm8.
Note that these instructions are obsolete, that's not the same as not implemented.
I don't know what uses sys-libs/db. On my desktop, I get
Code: Select all
$ equery d sys-libs/db
* These packages depend on sys-libs/db:
app-office/orage-4.12.1 (berkdb ? >=sys-libs/db-4)
dev-lang/perl-5.22.2 (berkdb ? sys-libs/db)
dev-lang/python-2.7.11-r2 (berkdb ? sys-libs/db:5.3)
(berkdb ? sys-libs/db:5.2)
(berkdb ? sys-libs/db:5.1)
(berkdb ? sys-libs/db:5.0)
(berkdb ? sys-libs/db:4.8)
(berkdb ? sys-libs/db:4.7)
(berkdb ? sys-libs/db:4.6)
(berkdb ? sys-libs/db:4.5)
(berkdb ? sys-libs/db:4.4)
(berkdb ? sys-libs/db:4.3)
(berkdb ? sys-libs/db:4.2)
dev-libs/redland-1.0.17-r1 (berkdb ? sys-libs/db)
net-nds/openldap-2.4.44 (berkdb ? <sys-libs/db-6.0)
(berkdb ? sys-libs/db:5.3)
(berkdb ? sys-libs/db:5.1)
(berkdb ? sys-libs/db:4.8)
(berkdb ? sys-libs/db:4.7)
(berkdb ? sys-libs/db:4.6)
(berkdb ? sys-libs/db:4.5)
(berkdb ? sys-libs/db:4.4)
sys-apps/iproute2-4.5.0 (berkdb ? sys-libs/db)
sys-libs/pam-1.3.0 (berkdb ? >=sys-libs/db-4.8.30-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,\
abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
This just came in.
Posted: Tue Aug 02, 2016 4:04 am
by Zucca
Posted: Fri Sep 09, 2016 12:47 pm
by KAMIKAZE_
Could someone share a fully built stage with configs or even an image file, please?

Posted: Fri Sep 09, 2016 4:57 pm
by chithanh
What fully built stage do you want? The normal stage3 for armv7 and arm64 work fine.
Other than that, you will find images in the [post=7898580]64 bit thread[/post]:
Posted: Tue Sep 20, 2016 11:07 am
by Yamakuzure
For a while now my RPi3 is a brick.
I can use the normal terminal, and I can use xterm from within LxQT, but
not from within Lumina.
Other applications segfault after a few seconds. The Backtrace in gdb is always the same with frame 0 being:
Code: Select all
#0 malloc_consolidate (av=av@entry=0x76f5d79c <main_arena>) at malloc.c:4123
The address, of course, changes, but everything else is the same.
The very same applications ran fine until 2 weeks ago. I even recompiled my whole system.
Did anybody have this, too? Maybe my PI is broken?
Edit: My PI is fine. Switched the card with another one running Raspbian, and the issue is the same on the other PI.
Edit 2: Interesting. From within LxQT I can run xterm. From within Fluxbox, Openbox or Lumina I can not even get xterm to start.
But: If I do a startx as root firing up a twm without lightdm bein in front of it, xterm, Konsole, and everything else works just fine.
Edit 3: Wow. As a regular user TWM doesn't even start. Could it be my user profile? That would be really weird, no?
... but it *is* the profile. Dammit! Why didn't I try it out sooner? Everything, no matter from which DM/WM works just fine if I am root.
And now everything works fine again after I removed ~/.??*
filesystems
Posted: Thu Sep 22, 2016 3:40 pm
by Zucca
Hi. What filesystems you prefer to use on your Pi?
I plan to move some directories to an external USB stick (plug rather).
I wonder what would be the best fs for all the mmc partitions. Maybe some filesystem designed for flash storage? And what for the USB mass storage?
Posted: Fri Sep 23, 2016 9:59 am
by NeddySeagoon
Zucca,
You must use vfat for /boot or it won't
On the SDCard I use ext4 with journaling off. You don't need the extra writes and I keep mine backed up as from the original Pi days, mine often got trashed.
For a USB HDD, I use a mix of ext4 and ext4 with journaling off, depending on the filesystem content.
Throwaway content gets journaling off.
Posted: Sat Sep 24, 2016 9:30 pm
by Zucca
NeddySeagoon wrote:Throwaway content gets journaling off.
I plan to use my USB stick fot temporary files. Mainly for portage temp files and maybe swap. Although swap has its "own filesystem".
I wish there was RAM-based USB sticks. I don't mind the slowness of USB2.0 but rather the endurance.
Posted: Sat Sep 24, 2016 9:38 pm
by NeddySeagoon
Zucca,
A USB stick will be slow as its still FLASH.
I suspect a USB3 stick would move the bottleneck to the USB2 I/O but I've not tested.
There is another complication with a USB3 stick on the Pi. The USB2 may not power it.
I use a USB HDD that has its own PSU (not USB bus powered)
Posted: Sun Sep 25, 2016 1:56 am
by axl
i tried to use an external sata / usb thingie with a ssd drive as storage. the result was not as good as expected. on a pc it would do great. it would work usb3/sata3. on the pi it would only go usb2.
and did aweful. really.
it reminds me of the dreaded "southbridge" on intel platforms. the dreaded IO bridge where everything worked bad. so happy my nvme disk now resides with ram/cpu/videocard on the northbridge.
anyway... u can't speed up a pi. it's own cardreader is the fastest storage it has. you can only buy a really good card thingie and hope for the best. or use google to look for the wiki page with benchmarks which card works best.
what i do know, usb is not a viable option for pi and storage.
Posted: Sun Sep 25, 2016 8:50 am
by NeddySeagoon
axl,
I manage 5MB/sec on the SD card and 30MB/sec over USB.
Tested on a Pi 3 in 64 bit mode with hdparm -tT /dev/.
That's tested with a selection of SD cards but only one USB HDD.
Interesting
Posted: Sun Sep 25, 2016 3:26 pm
by Zucca
Interesting...
I thought the microSD slot with it's own bus would be fastest storage but no.
My tests tell the same story.
Code: Select all
/dev/mmcblk0:
Timing cached reads: 1172 MB in 2.00 seconds = 585.37 MB/sec
Timing buffered disk reads: 52 MB in 3.09 seconds = 16.84 MB/sec
Code: Select all
/dev/sda:
Timing cached reads: 1196 MB in 2.00 seconds = 597.35 MB/sec
Timing buffered disk reads: 100 MB in 3.05 seconds = 32.83 MB/sec
My USB stick is
Sandisk Ultra Fit USB3.0 16GB. So it's confirmed a working USB3.0 USB flash stick. :)