This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
ESPRESSOBin
Overview
This documents the basic setup for Marvell Espressobin ARM64 network switch-ish board. It appears to be the only similar-class Marvell board with open docs (ie, not protected by NDA). Googling reveals a mix of both proprietary and "open" resources (and github appears to contain a mix of both, so ignore links and other references to "extranet"). There appears to be one main site for the ESPRESSOBin boards, with the corresponding vendor sources mainly on github.
History
The Marvell Espressobin was originally a kickstarter board by Globalscale Technologies Inc. It is a high performance 64 bit dual-core networking computing platform based on the ARMv8 architecture and has low power consumption. The board is powered by Marvell's Armada 3700 dual-core SoC chipset which runs up to 1.2GHz.
Pros:
- Solid mainline support
- Great network/SATA performance
- Mini PCIe expansion slot
- 2 GbE LAN ports, 1 GbE WAN port
- USB 3 host port
- ATF-based boot protocol
- 1 GB or 2 GB RAM
Cons:
- no video/audio
- ATF-based boot protocol
- complicated u-boot upgrade
- availability
The Gentoo arm64 offering is still experimental at the time of writing. That means that very little is marked stable. Expect to use ACCEPT_KEYWORDS="~arm64" and then use package.accept_keywords too.
What Works
All the core hardware should be supported in latest mainline kernel (tested on 4.13.12) and u-boot 2017.11-rc4.
Network switch USB 2.0/3 MMC SATA PCIE UART over micro-USB Hardware Crypto
Untested
GPIO/SPI/I2C PCIe Mainline u-boot Note: u-boot lives in SPI flash
What's Required
Gentoo Install on a PC microSD card reader for the PC ESPRESSOBin board 12V PSU microSD card > 8G micro USB cable network cable
The contents of the microSD card will be wiped during the install.
Installation Overview
- Install crossdev on the PC
- Fetch the mainline kernel (or use the builder script)
- Partition the microSD card
- Fetch the Gentoo bits of the install
- Cross compile and install your kernel
- Setup networking and root passwd
- Boot with serial console to test
Install Crossdev on the PC
crossdev is Gentoos' tool for building cross compiler tool chains. Once it's installed, it will br used to build the arm64 kernel on the Gentoo PC.
root #emerge --ask crossdevwill install the crossdev tool.
Using Crossdev to Build A Cross Compiler
root #crossdev -t aarch64-unknown-linux-gnuYou may need to disable existing overlays first; at least crossdev-99999999 gets a little confused by overlays right now, and it does need its output overlay to be the primary one. After disabling your local overlays you should run crossdev with PORTDIR_OVERLAY set to where you want the crossdev output to go.
There are other parameters you can pass to crossdev too.
Do not use -S to build a stable toolchain, arm64 moves quickly
You can find some crossdev examples in the arm overlay; an example "fancy" crossdev command for arm64 might be:
root #PORTDIR_OVERLAY="/usr/local/armv8" USE="hardened multitarget lzma -multilib -openmp -go -fortran -jit" EXTRA_ECONF="--disable-multilib --disable-libsanitizer" crossdev -v -t aarch64-unknown-linux-gnu --ex-gdbCrossdev insists that many of the files in /etc/portage/ are directories
Convert files as crossdev asks e.g.
error: please convert /etc/portage/package.env to a directory
by appending _file to the existing filename
root #mv /etc/portage/package.env /etc/portage/package.env_filemaking the directory
root #mkdir /etc/portage/package.envthen moving package.env_file into the directory.
root #mv /etc/portage/package.env_file /etc/portage/package.envRinse and repeat until crossdev is happy.
crossdev will take a while. Its building
binutils: binutils-[latest] gcc: gcc-[latest] headers: linux-headers-[latest] libc: glibc-[latest]
When crossdev completes you will have a cross toolchain
user $$ gcc-config -l
[1] aarch64-unknown-linux-gnu-5.4.0 *
[2] aarch64-unknown-linux-gnu-5.4.0-vanilla
It will also create an arm64 target root in /usr/aarch64-unknown-linux-gnu/ This is used by cross emerge.
Pure cross compiling, other than the kernel, is out of scope of this guide.
Fetch, Configure and Build the Kernel
There are some prebuilt vendor kernel images for this board, but mainline is preferred. U-boot has a rather complicated build and flash process, and the latest vendor branch is not buildable anyway. The version of u-boot in SPI flash on the board I received is 2015.01-armada-17.02.0-g8128e91 and the default environment is set to boot from mmc.
Fetch the Kernel
In this case you have a choice to build "stock" mainline or gentoo-sources by hand, or use the kernel build scripts with some Armbian patches. Note there is now an ebuild in the arm overlay that incorporates the appropriate gentoo patches, mvebu64 patches, and the correct defconfig, see https://github.com/gentoo/arm/tree/master/sys-kernel/armv8multi-sources
One of the latter is recommended, since they also includes a proper defconfig for this machine (you need it to boot from sdcard).
So either use the builder scripts (borrowed from RCN repo and updated for ESPRESSOBin) or grab the defconfig and do it manually. If you don't already have a linux-stable tree the scripts will clone it for you (see the file system.sh.sample and copy it to system.sh, then set your CC prefix).
user $git clone https://github.com/sarnold/arm64-multiplatformuser $cd arm64-multiplatformUse the default branch v4.13.x, edit system.sh, then run build_kernel.sh and wait for your shiny new kernel in the dep[loy/ directory.
At the end of the build, it will output the kernel version string to export in your shell for the install commands later. Something like:
----------------------------- Script Complete eewiki.net: [user@localhost:~$ export kernel_version=4.13.12-aarch64-r0] -----------------------------
The build_kernel.sh script will start from a fresh clone of the kernel source, apply patches, run make menuconfig, etc. If you want to make any changes or fiddle in the kernel tree, rebuild using tools/rebuild.sh script instead (the latter will start a build using the existing tree).
Configure The Kernel
Once the scripts have cloned the kernel tree and applied any patches, you will see the menuconfig screen. Note the default config used should have all the required hardware support already enabled, but may not have all the network tools you want yet (the config is still a WIP).
More confident readers may be tempted to trim things out or add things now. A word of advice - don't, at least, not until the system boots.
Cross Compiling The Kernel
The scripts will use the toolchain arch set in system.sh but if you want to compile it manually the proper command line would be something like:
user $make ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu-Partition the microSD card
This Step Will Destroy ALL The Data on the Card
Background
The current vendor u-boot environment is already set to look for a kernel and device tree blob in the boot directory of the first partition, as well as use the first partition as root. Therefor you only need to make one partition (or at least make sdX1 the rootfs).
Many boards (even in mainline u-boot) do not yet support all ext4 defaults yet so 64bit metadata and checksums must be disabled
Partitioning
Depending on how the microSD card is connected to you PC, it my be /dev/sdX or /dev/mmcblkY
Check! Do Get It Right - Don't Ruin your PC Install
In the example below, it's /dev/sdb. Also, you can use a swapfile instead of a separate partition.
Clean the card and format with options
root #export DISK=/dev/your_sdcard_deviceroot #dd if=/dev/zero of=${DISK} bs=1M count=10Using the partitioning tool of your choice, make one partition on your microSD card.
root (/)
Using fdisk, and your microSD card block device, not the example /dev/sdb unless it's correct for your setup
root #fdisk ${DISK} Use ext4 for root:
root #mkfs.ext4 -L rootfs -O ^metadata_csum,^64bit -T news ${DISK}1 -T news makes more inodes for lots of small files
The i-node count cannot be changed after filesystem creation and can limit the number of files on a files system. The Gentoo repository alone needs over 17,000 i-nodes.
Fetch the Gentoo bits of the install
To make it easy to cross refer to the Gentoo_Handbook
root #mkdir /mnt/gentooMount the microSD card root filesystem at /mnt/gentoo
root #mount /dev/sdb1 /mnt/gentooInstall the arm64 Stage 3
Following the Gentoo_Handbook fetch the arm64 stage3 and untar it to /mnt/gentoo in the normal way.
/mnt/gentoo/tmp should be empty. Clear it now.
root #rm -rf /mnt/gentoo/tmp/*Install a Portage Snapshot
This step is not actually needed to boot but emerge won't work without it
Following the Gentoo_Handbook fetch and unpack a portage snapshot in the normal way.
Careful readers can copy their host /usr/portage as long as ./packages and ./distfiles are omitted.
Populating /boot
All that's needed here is the kernel binary and the proper device tree blob. Note the file names have to match what the vendor u-boot expects, so just copy the files as-is and make symlinks to the required names (see below).
Install the Kernel to the microSD Card
The kernel was built above, now to install it.
The kernel is in three parts
kernel binary device tree blob kernel modules
Install The Kernel Binary
As root or via sudo, copy the kernel binary from the build location, either from your kernel tree (/path/to/your/tree/linux/arch/arm64/boot/Image) or the deploy directory:
user $sudo cp -v ./arm64-multiplatform/deploy/${kernel_version}.Image /mnt/gentoo/boot/Install The Device Tree
The device tree binary (.dtb) describes the hardware to the kernel. This avoids having all the existing hardware configurations hard coded into the kernel.
Extract the following .dtb file from ./arm64-multiplatform/deploy/${kernel_version}-aarch64-r0-dtbs.tar.gz and copy it to the boot directory:
user $sudo cp -v ./arm64-multiplatform/deploy/armada-3720-espressobin.dtb /mnt/gentoo/boot/Create the Symlinks for Vendor U-Boot
Change to the mounted boot directory and symlink the files to the expected names:
user $cd /mnt/gentoo/bootuser $sudo ln -s ${kernel_version}.Image Imageuser $sudo ln -s armada-3720-espressobin.dtb armada-3720-community.dtbuser $cd -
Install The Kernel Modules
If you built your own kernel by hand, you'll want to run the modules_install arg. From the top of the kernel tree, install the kernel modules
user $cd /path/to/your/tree/linuxuser $ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make modules_install INSTALL_MOD_PATH=/mnt/gentooOtherwise, unpack the kernel modules tarball from the deploy directory:
user $sudo tar xfv ./arm64-multiplatform/deploy/${kernel_version}-modules.tar.gz -C /mnt/gentoo/
Checking The Kernel Install
user $ls /mnt/gentoo/boot
4.13.12-aarch64-r0.Image armada-3720-espressobin.dtb Image
armada-3720-community.dtb config-4.13.12-aarch64-r0
user $ls /mnt/gentoo/lib/modules
4.13.12-aarch64-r0
Shows that the kernel and modules were installed to the correct locations.
Marvell ESPRESSOBin Peripherals
Now that the base operating system is in place, you will need to do some file configuration by hand to get the peripherals working.
Serial Port Configuration
The Gentoo Stage3 comes with the default Gentoo serial port configuration, however, you need to make sure the default serial ports are commnted out, and set the board-specific serial port.
Open up /etc/inittab -
root # nano -w /etc/inittabMake sure the ttyS serial port lines are commented, then find this line at the bottom and set the speed and tty port device -
/etc/inittabT0:12345:respawn:/sbin/agetty 115200 ttyMV0 vt100
Save and exit the file. This ensures Gentoo will launch a login getty on the correct serial interface.
Network Setup
It seems like all network switch setups are unique, but there is an effort to converge using the Distributed Switch Architecture (DSA). The ESPRESSOBin has two LAN ports and one WAN port, which apparently need a virtual "eth0" to be configured correctly. This means eth0 must be "up" (but not configured) before the actual network devices are usable. Unless you make udev naming rules, the default interfaces are lan0, lan1, and wan. Upstream docs name the left-most port as "lan1" which is where you want to plug in for local use.
bond0: flags=5122<BROADCAST,MASTER,MULTICAST> mtu 1500
ether a6:e9:9a:6c:17:e1 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
dummy0: flags=130<BROADCAST,NOARP> mtu 1500
ether d6:73:f5:c7:65:2c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::f2ad:4eff:fe03:861b prefixlen 64 scopeid 0x20<link>
ether f0:ad:4e:03:86:1b txqueuelen 532 (Ethernet)
RX packets 203950 bytes 145809090 (139.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 145454 bytes 42938767 (40.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 8
lan0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether f0:ad:4e:03:86:1b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.29 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::f2ad:4eff:fe03:861b prefixlen 64 scopeid 0x20<link>
ether f0:ad:4e:03:86:1b txqueuelen 1000 (Ethernet)
RX packets 203950 bytes 141322190 (134.7 MiB)
RX errors 0 dropped 15488 overruns 0 frame 0
TX packets 145480 bytes 41953390 (40.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 41 bytes 2720 (2.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 41 bytes 2720 (2.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wan: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether f0:ad:4e:03:86:1b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The corresponding Gentoo network config needs all of these enabled, however, only lan1 is needed for initial setup. Here is the initial config for one network interface:
user $cat /etc/conf.d/net# This blank configuration will automatically use DHCP for any net.* # scripts in /etc/init.d. To create a more complete configuration, # please review /usr/share/doc/openrc*/net.example* and save your configuration # in /etc/conf.d/net (this file :]!). dns_domain_lo="your.domain" config_eth0=null config_lan1="192.168.10.29 netmask 255.255.255.0 brd 192.168.10.255" routes_lan1="default via 192.168.10.1" dns_domain_lan1="your.domain" dns_servers_lan1="8.8.8.8" rc_net_lan1_need="net.eth0" # The network scripts are now part of net-misc/netifrc # In order to avoid sys-apps/openrc-0.12 from removing # this file, this comment was # added; you can safely remove this comment. Please see # /usr/share/doc/netifrc*/README* for more information.
Remember to start both eth0 and lan1.
Root Password
You need this to be able to log in at all
There are several ways to generate a password hash for /etc/shadow; usually it suffices to copy the hash from another system.
All stage3 root filesystems should use an /etc/shadow root entry
root:x::0:99999:7:::
Instead of copying the hash, you can also use openssl to generate a fresh one:
- edit /mnt/gentoo/etc/shadow so root can login:
root #openssl passwd -1
- grab hash output, edit /mnt/gentoo/etc/shadow, and put here:
/mnt/gentoo/etc/shadowroot:<hash_output>:10770:0:::::
The password can always be changed once you are logged in.
/etc/fstab
On this board, the microSD card will be /dev/mmcblk0 with one partition, /dev/mmcblk0p1
Edit /mnt/gentoo/etc/fstab to match.
root #nano -w /mnt/gentoo/etc/fstab/swapfile none swap sw 0 0 /dev/mmcblk0p1 / ext4 noatime 0 1
Boot the Board to Test
Unmount the microSD card.
root #umount /mnt/gentoo/When the prompt returns, move the microSD card to the board, plug in micro-usb and power cables and open a console using your favorite tool, then plug in the AC side and power it up.
Log in at the serial console as root. Nothing was added to any runlevels during the install, so networking was not started, nor anything that depends on networking, like ntpd and sshd.
Many embedded boards do not have a hardware real time clock. The time will probably be Jan 1, 1970; note you can use busybox-ntpd to set the clock after the network is up.
What Next
As always with Gentoo, if it booted, that's the hard bit done.
All The setup steps in the Gentoo Handbook Fix the MAC address or use a static IP Allow root logins via ssh Add a crond, a logger and other things the handbook does before the reboot. Add Kernel Sources (or at least the .config)
Random Hints
Boot from SATA
Yes, it's actually fairly easy to boot directly from an SSD connected to the SATA controller without using the micro-SDCard at all. For this to work, setup the SSD the same way as the card (hint: you can just rsync everything on the card to your SSD). The make the u-boot changes shown below.
The default u-boot environment has several variables set for NFS and MMC card, but the key one is "bootcmd" which defaults to the card slot (note it may point "root" to the first or second partition depending on the vendor configuration. Googling will bring up the vendor page with how to boot a bricked device from SATA and restore the u-boot in SPI flash; ignore that (unless your board is really bricked).
So, switching jumpers simply to boot from the SATA device is not needed, just two modified u-boot environment variables will do it. To make this change, just pop out the SDCard and connect a serial console as above, then power it up and hit a key to stop autoboot to get a u-boot prompt.
Booting Trusted Firmware
BL1: v1.2(release):armada-17.02.0:
BL1: Built : 09:41:56, Jun 2 2NOTICE: BL2: v1.2(release):armada-17.02.0:
NOTICE: BL2: Built : 09:41:57, Jun 2 20NOTICE: BL31: v1.2(release):armada-17.02.0:
NOTICE: BL31:
U-Boot 2015.01-armada-17.02.0-g8128e91 (Jun 02 2017 - 09:41:51)
I2C: ready
DRAM: 1 GiB
Board: DB-88F3720-ESPRESSOBin
CPU @ 1000 [MHz]
L2 @ 800 [MHz]
TClock @ 200 [MHz]
DDR @ 800 [MHz]
Comphy-0: PEX0 2.5 Gbps
Comphy-1: USB3 5 Gbps
Comphy-2: SATA0 5 Gbps
Now running in RAM - U-Boot at: 3ff2b000
U-Boot DT blob at : 000000003fa18168
MMC: XENON-SDHCI: 0
SF: Detected W25Q32DW with page size 256 Bytes, erase size 4 KiB, total 4 MiB
PCIE-0: Link down
SCSI: Target spinup took 0 ms.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
Net: neta0
Hit any key to stop autoboot: 3 0
Marvell>>
Once you see the prompt above you can try some commands like "printenv" and "help". For example:
Marvell>>printenv
baudrate=115200
bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p2 rw ip=0.0.0.0:0.0.0.0:10.4.50.254:255.255.255.0:marvell:eth0:none nfsroot=0.0.0.0:/srv/nfs/
bootcmd=mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p1 rw rootwait net.ifnames=0 biosdevname=0; booti $kernel_addr - $fdt_addr
bootdelay=3
console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000
eth1addr=00:00:00:00:51:82
eth2addr=00:00:00:00:51:83
ethact=neta0
ethaddr=F0:AD:4E:03:86:1B
ethprime=egiga0
fdt_addr=0x1000000
fdt_high=0xffffffffffffffff
fdt_name=boot/armada-3720-community.dtb
gatewayip=10.4.50.254
get_images=mmc dev 0; fatload mmc 0 $kernel_addr $image_name; fatload mmc 0 $fdt_addr $fdt_name; run get_ramfs
get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x3000000; tftp $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi
hostname=marvell
image_name=boot/Image
initrd_addr=0xa00000
initrd_size=0x2000000
ipaddr=0.0.0.0
kernel_addr=0x2000000
loadaddr=0x2000000
loads_echo=0
netdev=eth0
netmask=255.255.255.0
ramfs_addr=-
ramfs_name=-
root=root=/dev/mmcblk0p2 rw
rootpath=/srv/nfs/
serverip=0.0.0.0
set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params
stderr=serial
stdin=serial
stdout=serial
Environment size: 1480/65532 bytesThe variables we need to modify to switch defaults from SDCard partition 1 to SATA partition 1 are "bootargs" and "bootcmd". To change them, we need to run "setenv FOO" for each one, but that will only change them temporarily (suitable for testing). To save the changes to flash, we'll need to run the saveenv" command once we're happy with the changes.
The following changes work for me, but as always, YMMV. Test them first, save them after you verify they work for you.
Change the required variables:
Marvell>>setenv bootargs "$console root=/dev/sda1 rw rootwait net.ifnames=0 biosdevname=0" Marvell>>setenv bootcmd "scsi scan; scsi dev 0; ext4load scsi 0 $kernel_addr $image_name; ext4load scsi 0:1 $fdt_addr $fdt_name; booti $kernel_addr - $fdt_addr" Test the changes
Marvell>>run bootcmd Setting SCSI to 0
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
scanning bus 0 for devices...
Device 0: (0:0) Vendor: ATA Prod.: C400-MTFDDAK128M Rev: 040H
Type: Hard Disk
Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
Invalid port number 2
Invalid port number 3
Invalid port number 4
Invalid port number 5
Invalid port number 6
Invalid port number 7
Found 1 device(s).
SCSI device 0:
Device 0: (0:0) Vendor: ATA Prod.: C400-MTFDDAK128M Rev: 040H
Type: Hard Disk
Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
... is now current device
14895616 bytes read in 709 ms (20 MiB/s)
7466 bytes read in 50 ms (145.5 KiB/s)
## Flattened Device Tree blob at 01000000
Booting using the fdt blob at 0x1000000
Using Device Tree in place at 0000000001000000, end 0000000001004d29
Starting kernel ...
If it works, great! If not, check the console output for errors, look for typos, etc. Once you've verified the changes do what you want, save them:
Marvell>>saveenv WiFi and Bluetooth
Options are mainly PCIe or USB, so take your pick and report back.
CFLAGS
This works quite well, except for the packages where it doesn't work...
LINK_OPTS="-flto=2"
VEC_OPTS="-ftree-vectorize -ftree-loop-distribution -fvect-cost-model=cheap"
BASE_TUNE_OPTS="-march=armv8-a -mcpu=cortex-a53+simd"
TUNE_OPTS="-march=armv8-a+crc+fp+simd -mabi=lp64 -mcpu=cortex-a53+crc+fp+simd"
#CFLAGS="${BASE_TUNE_OPTS} -O2 -pipe"
CFLAGS="${TUNE_OPTS} -O2 -pipe ${VEC_OPTS} ${LINK_OPTS}"
CXXFLAGS="${CFLAGS}"
LDFLAGS="${CFLAGS} -fuse-linker-plugin"
CPU_FLAGS_ARM="edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 aes sha1 sha2 crc32 v4 v5 v6 v7 v8 thumb2"
Note gcc-6.x allows the use of -march=native but that will prevent the use of distcc. The above is the same as gcc-6.3 would set for -march=native anyway.
ACCEPT_KEYWORDS
Outside of the @system set, arm64 is either testing or keyword masked. Set
ACCEPT_KEYWORDS="~arm64"
and expect to use package.accept_keywords too.
The stage 3 tarball has been built with gcc-4.9 was gcc-5.4 is in testing ...
Upgrade gcc then rebuild all of the installed C++ software.
News item 2015-10-22 GCC 5 Defaults to the New C++11 ABI
MAKEOPTS
With only 1G RAM, and two cores, the conventional
MAKEOPTS="-j3"
could be a bit aggressive for building larger things. It will force swapping or even appear to lock up completely, to the point where it won't even respond to the console. Unlike many other boards that may segfault under heavy load, this board will try to swap everything out (and hasn't locked up yet).
Use files in /etc/portage/env/ and entries in /etc/portage/package.env to set MAKEOPTS on a per package basis.
Networking
The basic config given above works fine for "typical" building and testing; if you want to make a firewall/gateway/router, that's beyond the scope of this HowTo.
sshd
The default configuration for sshd will not allow password based root logins.
add your ssh public key for root make a normal user in the wheel group edit /etc/ssh/sshd_config to allow password based root logins
Updating The Tool Chain
Once you boot, you may have the desire to update @world first thing. However, as of the time of this writing, the latest stage3 for arm64 was built in December 2016. A lot of things in the tool chain will be out of date with what is on the current Portage tree. Once you've booted the board and confirmed that you have an internet connection, you'll want to first run emerge --sync to get the absolute latest tree, then run perl-cleaner --all to get all of your Perl packages up to date.
root # emerge --sync
root # perl-cleaner --all
root # emerge -auDN @worldUseful Packages
Network Time Sync
This board does not have a hardware real time clock on board. There are vendors online where you can order RTC modules made for the standard interfaces, but if you don't plan to run one, I highly recommend installing a NTP client.
First, set the initial time using the 'date' command. Date and time will be entered in mmddhhmmyyyy format and the time is in 24-hr format -
root #date mmddhhmmyyyyAs an example, if the time is 10:05PM on 7/31/2017 -
root # date 073122052017As with most things Gentoo, the NTP daemon is just an emerge away -
root # emerge --ask net-misc/ntpRemove the hardware clock service hwclock from the boot runlevel and replace it with the software clock service swclock -
root # rc-update del hwclock boot
root # rc-update add swclock bootMake sure you have the correct time zone set to the area which most closely matches your locale in /usr/share/zoneinfo -
root # ls /usr/share/zoneinfo
root # echo "<YOUR_TIME_ZONE>" > /etc/timezoneAs an example, if you live in California, you would do -
root # echo "America/Los_Angeles" > /etc/timezoneInstall your timezone libraries -
root # emerge --ask sys-libs/timezone-dataStart the NTP client and add it to the default runlevel -
root # rc-service ntp-client start
root # rc-update add ntp-client defaultWhere to Get Help
On Internet Relay Chat
irc.freenode.net#gentoo-arm irc.freenode.net#gentoo-embedded
On the Gentoo Forums, start a new topic in the Gentoo on ARM forum.
Acknowledgements
Everyone contributing to the arm64 software base.
Especially everyone...