Raspberry Pi 3 - 64 Bit Operation

[NeddySeagoon]

schorsch_76,

Lots of things in my cross compile involving g++ have suddenly started to work since I added.

Code: Select all

CXX="/usr/x86_64-pc-linux-gnu/aarch64-armv8a-linux-gnueabi/gcc-bin/5.3.0/aarch64-armv8a-linux-gnueabi-g++"

to /usr/aarch64-armv8a-linux-gnueabi/etc/portage./make.conf.

Its on 5 of 14 of the things in @system that wouldn't build because I had to set USE="-cxx" to get anything to work.

Aww ... gcc just failed.

Code: Select all

/usr/aarch64-armv8a-linux-gnueabi/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/libcpp/charset.c:1:0: error: bad value (armv8-a+crc) for -march= switch
 /* CPP Library - charsets
 ^
/usr/aarch64-armv8a-linux-gnueabi/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/libcpp/charset.c:1:0: error: bad value (cortex-a53) for -mtune= switch

--- Edit ---

There is a new BINHOST in my collection.

[schorsch_76]

Dear Neddy,

right now i try with the people on the gcc bugzilla to build a fully working gcc and g++. It seems we need a working g++ and libstdc++ to build a gcc. I hope with their support to get it fully working,

EDIT: Unbelievable! With your binhost, you could install most just like a binary distro

[NeddySeagoon]

schorsch_76,

There are a few things that will never cross compile. Perl being one of them, although there are some version specific patches around.
Not having a native gcc and g++ is a pain.

--- Edit ---

I have /usr/aarch64-armv8a-linux-gnueabi/tmp/portage/sys-devel/gcc-4.9.3/work/build built (I think) but I had to do it in two goes.
I have a complete native aarch64-armv8a-linux-gnueabi C and C++ compiler in bits in the build location.

I'm fairly sure if I run wake install, I'll regret it :)

I need to learn how to pick up a cross emerge in the middle, so gcc gets installed into the target root and not my amd64 host root.
I'm quite keen to get that right first time too.

[schorsch_76]

What failed that it stopped?

[schorsch_76]

I checked the gcc changelog. As they write, with gcc 4.8 they need g++ to build. Lets see if we can build gcc 4.7 ....

https://gcc.gnu.org/gcc-4.8/changes.html

GCC 4.8 Release Series
Changes, New Features, and Fixes

Caveats

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003. For more details on the rationale and specific changes, please refer to the C++ conversion page.

EDIT: I think about to use the Debian gcc archive from [1], extract it on the target and try this to compile our gentoo gcc.... Neddy: What do you think about it?
[1] http://ftp.de.debian.org/debian/pool/main/g/gcc-5/

[NeddySeagoon]

schorsch_76,

gcc-4.7.4 does not support armv8a. I tried it but the build failed with an error along those lines.

gcc-4.9-3 builds but it fails because something can't build or run a test program.
However, if you go into the bowels of the failed build and run make, it completes without error.
So I have a completed cross compiled gcc-4.9.4, in the build directory that I need to coax the ebuild to install properly.

I did consider finding a random native compiler but I would really like to use gcc-config and that's a Gentoo thing.

[schorsch_76]

Yes, you are right, I want to build it myself too. I tried to setup a SD card with the debian compiler, just to get the configure line but i could not get it installed as the RPi misses Net and everything. I tried sneakersnet but i failed to install it because the rootfs image had a too old libc6 installed.

So i tried to build the gcc again with different library versions. read through the gcc documentation ....

As i had there no success, i tried to get the usb working. The devicetree file is missing a lot of things, when i compare it to the 32 bit version. That is the reason why USB is not working and all other things .... So i try to read into this and try to compile the gcc. There was a blog post which said:

http://www.airs.com/blog/archives/492

Normally when things fail to fit together in a reasonable way, you assume you’re on the wrong path. That’s a false indicator in the cross-toolchain world. Of course, you might still be on the wrong path. But don’t assume that because nothing quite works that you are doing the wrong thing.

But as debian and other got the 5.3 line compiled, there must be a path

[NeddySeagoon]

schorsch_76,

I've messed up

Code: Select all

crossdev -t aarch64-armv8a-linux-gnueabi

is incorrect.

It needs to be

Code: Select all

crossdev -t aarch64-unknown-linux-gnu

I'll start over. Its not time wasted, I've learned some valuable lessons that I won't need to relearn.

[Irre]

I have a silly question. Is it possible to test clang?
http://clang.llvm.org/docs/CrossCompilation.html

[schorsch_76]

I have snopped a Little through the two defconfigs. The 64 bit zeldin kernel has a _lot_ of modules deactivated. I try to get somehow the usb/ethernet working that we can get rid of the sneakersnet.

About clang: I havent tried it yet. From what i read, it seems to be easier ..... but about cross compiling a compiler ... seems to be more compilcated.

[NoName1337]

Successfully compiled gcc for aarch64 by slightly modifying your script. It seems to be related to this already fixed bug[1]. Going through the mailinglist for the proposed patch I found this suggested solution by Jakub Jelinek[2]. Applying his solution did the trick for me.

The modified script I ran (original by Jeff Preshing [3] ) looks now like this. I introduced the BUILD variable because the gcc docs discourage the use of host without the use of build [4]. BUILD is x86_64-linux-gnu because I cross compiled gcc for aarch64 on my desktop.

Code: Select all

#! /bin/bash
set -e
trap 'previous_command=$this_command; this_command=$BASH_COMMAND' DEBUG
trap 'echo FAILED COMMAND: $previous_command' EXIT

#-------------------------------------------------------------------------------------------
# This script will download packages for, configure, build and install a GCC cross-compiler.
# Customize the variables (INSTALL_PATH, TARGET, etc.) to your liking before running.
# If you get an error and need to resume the script from some point in the middle,
# just delete/comment the preceding lines before running it again.
#
# See: http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler
#-------------------------------------------------------------------------------------------

INSTALL_PATH=/opt/cross
BUILD=x86_64-linux-gnu
HOST=aarch64-linux-gnu
TARGET=aarch64-linux-gnu
USE_NEWLIB=0
LINUX_ARCH=arm64
CONFIGURATION_OPTIONS="--disable-multilib" # --disable-threads --disable-shared
PARALLEL_MAKE=-j1
BINUTILS_VERSION=binutils-2.25
GCC_VERSION=gcc-5.3.0
LINUX_KERNEL_VERSION=linux-4.5
GLIBC_VERSION=glibc-2.22
MPFR_VERSION=mpfr-3.1.4
GMP_VERSION=gmp-6.0.0a
MPC_VERSION=mpc-1.0.2
ISL_VERSION=isl-0.16.1
CLOOG_VERSION=cloog-0.18.1
#export PATH=$INSTALL_PATH/bin:$PATH
export CC=$HOST-gcc
export CXX=$HOST-g++

# Download packages
export http_proxy=$HTTP_PROXY https_proxy=$HTTP_PROXY ftp_proxy=$HTTP_PROXY
wget -nc https://ftp.gnu.org/gnu/binutils/$BINUTILS_VERSION.tar.gz
wget -nc https://ftp.gnu.org/gnu/gcc/$GCC_VERSION/$GCC_VERSION.tar.gz
if [ $USE_NEWLIB -ne 0 ]; then
    wget -nc -O newlib-master.zip https://github.com/bminor/newlib/archive/master.zip || true
    unzip -qo newlib-master.zip
else
    wget -nc https://www.kernel.org/pub/linux/kernel/v4.x/$LINUX_KERNEL_VERSION.tar.xz
    wget -nc https://ftp.gnu.org/gnu/glibc/$GLIBC_VERSION.tar.xz
fi
wget -nc https://ftp.gnu.org/gnu/mpfr/$MPFR_VERSION.tar.xz
wget -nc https://ftp.gnu.org/gnu/gmp/$GMP_VERSION.tar.xz
wget -nc https://ftp.gnu.org/gnu/mpc/$MPC_VERSION.tar.gz
wget -nc ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL_VERSION.tar.bz2
wget -nc ftp://gcc.gnu.org/pub/gcc/infrastructure/$CLOOG_VERSION.tar.gz

# Extract everything
for f in *.tar.gz; do tar -xzf $f; done
for f in *.tar.bz2; do tar -xjf $f; done
for f in *.tar.xz; do tar -xJf $f; done

#Apply proposed patch for always_inline by Jakub Jelinek https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02505.html
cd $GCC_VERSION
sed -i -e 's/__always_inline/__libitm_always_inline/g' libitm/local_atomic
cd ..

# Make symbolic links
cd $GCC_VERSION
ln -sf `ls -1d ../mpfr-*/` mpfr
ln -sf `ls -1d ../gmp-*/` gmp
ln -sf `ls -1d ../mpc-*/` mpc
ln -sf `ls -1d ../isl-*/` isl
ln -sf `ls -1d ../cloog-*/` cloog
cd ..

# Step 1. Binutils
mkdir -p build-binutils
cd build-binutils
../$BINUTILS_VERSION/configure --prefix=$INSTALL_PATH --build=$BUILD --target=$TARGET $CONFIGURATION_OPTIONS --host=$HOST
make $PARALLEL_MAKE
make install
cd ..

# Step 2. Linux Kernel Headers
if [ $USE_NEWLIB -eq 0 ]; then
    cd $LINUX_KERNEL_VERSION
    make ARCH=$LINUX_ARCH INSTALL_HDR_PATH=$INSTALL_PATH/$TARGET headers_install
    cd ..
fi

# Step 3. C/C++ Compilers
mkdir -p build-gcc
cd build-gcc
if [ $USE_NEWLIB -ne 0 ]; then
    NEWLIB_OPTION=--with-newlib
fi
../$GCC_VERSION/configure --prefix=$INSTALL_PATH --build=$BUILD --host=$HOST --target=$TARGET --enable-languages=c,c++ $CONFIGURATION_OPTIONS $NEWLIB_OPTION
make $PARALLEL_MAKE all-gcc
make install-gcc
cd ..

if [ $USE_NEWLIB -ne 0 ]; then
    # Steps 4-6: Newlib
    mkdir -p build-newlib
    cd build-newlib
    ../newlib-master/configure --build=$BUILD --host=$HOST --prefix=$INSTALL_PATH --target=$TARGET $CONFIGURATION_OPTIONS
    make $PARALLEL_MAKE
    make install
    cd ..
else
    # Step 4. Standard C Library Headers and Startup Files
    mkdir -p build-glibc
    cd build-glibc
    ../$GLIBC_VERSION/configure --prefix=$INSTALL_PATH/$TARGET --build=$BUILD --host=$TARGET --target=$TARGET --with-headers=$INSTALL_PATH/$TARGET/include $CONFIGURATION_OPTIONS
    make install-bootstrap-headers=yes install-headers
    make $PARALLEL_MAKE csu/subdir_lib
    install csu/crt1.o csu/crti.o csu/crtn.o $INSTALL_PATH/$TARGET/lib
    $TARGET-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o $INSTALL_PATH/$TARGET/lib/libc.so
    touch $INSTALL_PATH/$TARGET/include/gnu/stubs.h
    cd ..

    # Step 5. Compiler Support Library
    cd build-gcc
    make $PARALLEL_MAKE all-target-libgcc
    make install-target-libgcc
    cd ..

    # Step 6. Standard C Library & the rest of Glibc
    cd build-glibc
    make $PARALLEL_MAKE
    make install
    cd ..
fi

# Step 7. Standard C++ Library & the rest of GCC
cd build-gcc
make $PARALLEL_MAKE all
make install
cd ..

trap - EXIT
echo 'Success!'

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164
[2] https://gcc.gnu.org/ml/gcc-patches/2014 ... 02505.html
[3] http://preshing.com/20141119/how-to-bui ... -compiler/
[4] https://gcc.gnu.org/onlinedocs/gccint/C ... Terms.html

[schorsch_76]

Thanks! I try it at the moment

I got one step closer to get the usb running

[schorsch_76]

I tried to use the dwg_otg driver from arm instead of the DWC2 driver but that didnt compile- I tried to fix it, but i havent had enough knowledge about fqi and stuff. So i tried to dig in the DWC2 driver.

Code: Select all

Pi_3 64_bit 3f980000.usb # cat usb1/bMaxPower 
0mA

This is related to the dmesg msg;

Code: Select all

[    0.187217] 3f980000.usb supply vusb_d not found, using dummy regulator
[    0.187246] 3f980000.usb supply vusb_a not found, using dummy regulator
[    0.365674] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1

greping through the sources showed me, that it wants in the device tree a "vusb_a" and "vusb_d" regulators.

Code: Select all

georg@hammerhead ~/intern/Dokumente/Entwicklung/rpi3/src/linux-2.6 $ grep -riHn "not found, using dummy regulator" drivers/*
drivers/regulator/core.c:1572:		pr_warn("%s supply %s not found, using dummy regulator\n",

Code: Select all

	/*
	 * Assume that a regulator is physically present and enabled
	 * even if it isn't hooked up and just provide a dummy.
	 */
	if (have_full_constraints() && allow_dummy) {
		pr_warn("%s supply %s not found, using dummy regulator\n",
			devname, id);

		rdev = dummy_regulator_rdev;
		get_device(&rdev->dev);
		goto found;
	/* Don't log an error when called from regulator_get_optional() */
	} else if (!have_full_constraints() || exclusive) {
		dev_warn(dev, "dummy supplies not allowed\n");
	}

Now the big question: On what gpio is it? I tried to grep through the 32bit pi kernel but it uses the dwg_otg driver. This driver seems not to contain the word "regulator"


Some exampleshow it should look like

Code: Select all

georg@hammerhead ~/intern/Dokumente/Entwicklung/rpi3/src/linux-2.6 $ grep -riHn vusb_d arch/*
arch/arm/boot/dts/exynos4210-universal_c210.dts:284:	vusb_d-supply = <&ldo3_reg>;
arch/arm/boot/dts/exynos3250-rinato.dts:160:	vusb_d-supply = <&ldo15_reg>;
arch/arm/boot/dts/s5pv210-aquila.dts:357:	vusb_d-supply = <&ldo8_reg>;
arch/arm/boot/dts/exynos4412-trats2.dts:475:	vusb_d-supply = <&ldo15_reg>;
arch/arm/boot/dts/exynos4210-trats.dts:263:	vusb_d-supply = <&vusb_reg>;
arch/arm/boot/dts/s5pv210-goni.dts:335:	vusb_d-supply = <&ldo8_reg>;
arch/arm/boot/dts/exynos3250-monk.dts:169:	vusb_d-supply = <&ldo15_reg>;
arch/arm/boot/dts/exynos4412-odroid-common.dtsi:194:	vusb_d-supply = <&ldo15_reg>;
arch/arm/boot/dts/bcm28155-ap.dts:77:		vusb_d-supply = <&usbldo_reg>;
georg@hammerhead ~/intern/Dokumente/Entwicklung/rpi3/src/linux-2.6 $ grep -riHn vusb_a arch/*
arch/arm/boot/dts/exynos4210-universal_c210.dts:285:	vusb_a-supply = <&ldo8_reg>;
arch/arm/boot/dts/exynos3250-rinato.dts:161:	vusb_a-supply = <&ldo12_reg>;
arch/arm/boot/dts/s5pv210-aquila.dts:356:	vusb_a-supply = <&ldo3_reg>;
arch/arm/boot/dts/exynos4412-trats2.dts:476:	vusb_a-supply = <&ldo12_reg>;
arch/arm/boot/dts/exynos4210-trats.dts:264:	vusb_a-supply = <&vusbdac_reg>;
arch/arm/boot/dts/s5pv210-goni.dts:334:	vusb_a-supply = <&ldo3_reg>;
arch/arm/boot/dts/exynos3250-monk.dts:170:	vusb_a-supply = <&ldo12_reg>;
arch/arm/boot/dts/exynos4412-odroid-common.dtsi:195:	vusb_a-supply = <&ldo12_reg>;
arch/arm/boot/dts/bcm28155-ap.dts:78:		vusb_a-supply = <&iosr1_reg>;

The dwg_otc driver ... No clue about it

Code: Select all

georg@hammerhead ~/Dokumente/Entwicklung/rpi3/src/linux-pi/drivers/usb/host $ grep -riHn regulator dwc_*
georg@hammerhead ~/Dokumente/Entwicklung/rpi3/src/linux-pi/drivers/usb/host $ grep -riHn vusb dwc_*
georg@hammerhead ~/Dokumente/Entwicklung/rpi3/src/linux-pi/drivers/usb/host $ 

Is there a electrical diagram available from the Raspberry Pi 3B?
This are the devices which are on this bus:

Code: Select all

Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub

Some other boards which had a similar issue. They fixed it wit the DTS
http://www.alteraforum.com/forum/archiv ... 50295.html

[schorsch_76]

@NoName1337: It works

Code: Select all

Pi_3 64_bit ~ # g++ main.cpp
Pi_3 64_bit ~ # ./a.out 
Hi C++

Now i try to compile the gentoo gcc on the raspberry. *Pressing thumbs*

[NoName1337]

@schorsch_76: Happy that I could help you with gcc Good luck building gentoo *pressing thumbs*
In terms of the usb problem: Did you have a look at https://github.com/raspberrypi/linux/tr ... rivers/usb? If the usb problem is not related to building a 64bit version, then any necessary patch should be in there. That are the sources that the rpi foundation uses for their kernel images.

[schorsch_76]

@schorsch_76: Happy that I could help you with gcc Good luck building gentoo *pressing thumbs*
In terms of the usb problem: Did you have a look at https://github.com/raspberrypi/linux/tr ... rivers/usb? If the usb problem is not related to building a 64bit version, then any necessary patch should be in there. That are the sources that the rpi foundation uses for their kernel images.

Yes, that i tried. My linux-pi tree is exact this source. The dwg_otg driver needs stuff from the 32 bit arm. That is what i tried.

[NoName1337]

Have at least one more candidate https://github.com/Broadcom/arm64-linux ... rivers/usb . It´s broadcom and arm64, so it sounds relatively promising.

[schorsch_76]

*doh*

Das probier ich morgen ...

https://github.com/Broadcom/arm64-linux ... 155-ap.dts[/code]

Code: Select all

	usbotg: usb@3f120000 {
		vusb_d-supply = <&usbldo_reg>;
		vusb_a-supply = <&iosr1_reg>;
		status = "okay";
	};

	usbphy: usb-phy@3f130000 {
		status = "okay";
	};
};

#include "bcm59056.dtsi"

&pmu {
	compatible = "brcm,bcm59056";
	interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
	regulators {
		camldo1_reg: camldo1 {
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			regulator-always-on;
		};

		sdldo_reg: sdldo {
			regulator-min-microvolt = <3000000>;
			regulator-max-microvolt = <3000000>;
		};

		sdxldo_reg: sdxldo {
			regulator-min-microvolt = <2700000>;
			regulator-max-microvolt = <3300000>;
		};

		usbldo_reg: usbldo {
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			regulator-always-on;
		};

		iosr1_reg: iosr1 {
			regulator-min-microvolt = <1800000>;
			regulator-max-microvolt = <1800000>;
			regulator-always-on;
		};
	};
};

[NeddySeagoon]

Team,

I've undone the damage and got back to where I was.

I've also started work on a Wiki page.
Still no native gcc though ... yet.

[schorsch_76]

@Neddy: Keep up the good work Sometimes you need to step back one or two steps to see forward

In the meantime in the raspberry forum we got the usb bus enumerating. BUT: As soon as we start to bring the network up, regardless if the internal usb-ethernet bridge or (in my case a mcs7830) the Pi hangs.

With the fixed script i got a native gcc running in /opt/cross. It compiled through the night but i have only one Pi3 so i stoped it. It was still compiling. During the next week i will let it run.

I upload the native opt/cross chain
It needs CC/CXX and LIB_LIBRARY_PATH exported.

[NeddySeagoon]

schorsch_76,

If the USB root hub works, I wouldn't worry too much about the wired network.
Wifi (with a dongle) and USB storage is the next thing ... then the other 3 cores.

[schorsch_76]

Dear Neddy,
here is the cross chain for /opt/cross
https://www.schorsch-tech.de/rpi3/cross-gcc-g++.tar.xz

I currently try to fiddle around to find a way to communicate with something over network

[NeddySeagoon]

schorsch_76,

Thank you. I have it. I probably won't do much with it until Sunday night, when it can emerge itself.

Meanwhile, I'm trying to get USB to work and framebuffer. USB without DMA won't be much fun.
Do you remember the PIO modes of IDE drives?

Its a lot of CPU load.

[NeddySeagoon]

schorsch_76,

With USB working, framebuffer console is practical (and works).
It did not need the regulator patch, just the turn off DMA patch.

You need simple framebuffer support in the kernel and to connect a mouse/keyboard on the working USB.
Oh, and to change /etc/inittab.

The uboot bootargs need to be updated if you want boot messages on the framebuffer console too.
Its nice to have a colour display back.

[schorsch_76]

Neddy,

Which framebuffer module have you used?