This is strictly for beginners and in order to happily upload your existing code to a completely new repository. It doesn’t teach good practices (very important).

After you complete this tutorial you may follow some of the amazing tutorials around to understand the logic behind code versioning, for example Atlassian’s git tutorial and Roger Dudler’s tutorial.

Create SSH key

Open your local terminal and type the following to generate a new, super-safe SSH using the OpenSSH format and the ed25519 algorithm, using the same email that you have in GitHub:

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C “yourgithub@email.com”

To add the key to the local ssh agent run the following:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Upload key to GitHub

Open your GitHub account and choose Settings

Choose SSH and GPG keys

Select New SSH key

Copy and paste the nameofed25519.pub file inside the white (key) box! It’s important to put the public file in there, otherwise the security key will be exposed!

Create a new repository on your GitHub account

In the upper-right corner use the + drop-down menu and choose New repository

As a name choose your preferred name (let’s call it here tuning-sounds)

You can add a README and license file (personally choice is GPL v3+) and click to Create repository.

Create a new repo locally

At this step, GitHub offers a nice command line tutorial that allows to create a new repository from the command line. If you have existing code, let’s say in a folder called my-existing-code get out of it cd.. and create a new one, with the same name we just gave the project in GitHub mkdir tuning-sounds; cd tuning-sounds

Now follow the steps that GitHub suggests, in my case (it will be different for you):

# pulling the online repo locally
git init
git remote add origin git@github.com:wizofe/tuning-sounds.git
git pull origin master

# pushing a first README
echo “# tuning-sounds” >> README.md
git add README.md
git commit -m “first commit”
git branch -M master
git push -u origin master

Amazing! You just pushed your first changes in the repo 🎊

Commit and push code

Now you are ready to move the existing contents in your existing folder (my-existing-code) to the new project (tuning-sounds) with the following:

cd ..
mv my-existing-code/* tuning-sounds/
cd tuning-sounds

git add .
git commit -m "Move existing code in the repo"
git push -u origin master

This is the way you’ll do all your future commits. It is suggests that you commit relevant changes and not whole bunch of code! (like we just did ;-)

A good practice is to divide by functionality, for example if you create a pre-processing part in your code, only add that, commit it and push it to the repo. That makes easier to refer in future and also roll-back if your new change doesn’t work or breaks anything.

Talking about that, a great practice is to have testing inside your code :)

Verify on GitHub

If you go back on your GitHub folder you should be able to see the new code. It should look similar to this:

Looking forward

A few things to read about for any future projects are the following:

• Use a .gitignore file which is a way to exclude files in the same directory as your code (especially if you have data/config files or anything which you don’t want to push online)
• Creating branches and then do a pull request online. It’s a good idea to create new branches when adding functionality on the code. This way, you can also add collaborators that are able to do a code review before you do a final merge!
• Git branching and workflow strategies
• Testing your code (look for a testbed for your favourite language)
• Enjoy!

What am I going to do?

Two weeks ago, I blogged about @microcolonel’s plan to port Redox OS to the Armv8 Architecture and specifically to the 64-bit AArch64 execution state.

In this edition, I’ll blog about my personal explorations of the following ⌨️

• Setting up the HiKey960 reference board (kindly offered by @microcolonel and ARM; thanks!) for Serial Communication to the host development system (Fedora Linux28)
• Sanity checking @microcolonel’s current status of Redox OS. As a first step, and as explained in that doc, I compiled the whole of Redox for x86_64 on a Debian Stretch 9 host.
• Building @microcolonel’s AArch64 Redox kernel development branch to get my first AArch64 entry into the Redox (micro) kernel!
• Exploring the possibility of chain loading U-Boot from UEFI (i.e. Use U-Boot as an EFI payload) . For more details on this, look at this SuSE paper.
• Getting on par with @microcolonel’s qemu based core kernel work on HiKey960 reference board. I will describe what works, where it fails, and the difficulties encountered.
• Sharing some interesting community links, a Stanford course for Raspberry Pi (spoiler: it includes writing low level code in RUST 😍) and some insight on UEFI, U-Boot and OS Booting. A good read for anyone entering the playing field!

A summary of work done since the last blog posting

At the time of writing the previous blog the plan was to target the Raspberry Pi 3 (Cortex A53) as a development platform because of its availability, popularity and community. Sadly, it seems that Broadcom went through a lot of shortcuts while implementing this specific design, which means features like GIC are half-there or completely missing, like in this case.

After a discussion with @microcolonel, he proposed and kindly sent me a HiKey960 reference SoC from the awesome Linaro 96Boards initiative. The quality of this board is definitely a lot better than the Raspberry Pi and the documentation is detailed and open. Great stuff.

I am also excited as I wait for an Asus Tinkerboard, offered by another member of the Redox community: @stratact. Thank you so much for your contribution and I hope I can put it to use someday! Looking at you Redox kernel!!!

Board Preparation

The HiKey960 needs a UART to USB cable (such as the Mezzanine board from 96Boards or any other 1.8V-compatible cable; beware that is not your usual 3V3/5V Amazon TTL2USB!)

Pin 1/2 is GND. Then, we need to connect the Pins 11 (TxD), 13 (RxD) to their equivalent on the cable.

The colors aren’t universal but in my case they went like:

• White — RxD from the USB side
• Green — TxD (same as above)
• Black — GND
• Pink (I suppose trying to be red) — Vcc [leave that unconnected]
• In case that you need there’s also an active low reset available on pin 6 of the 40 pin connector. A jumper from there to GND will reset the board and set it to fastboot mode (optional)

For reference, see above for a photo of this setup.

If everything goes well you will be welcomed with a beautiful boot sequence and kernel messages from the stock Android AOSP installation:

Sanity check the Redox build environment

Here is the summary of my process, mainly following @microcolonel’s How-To but improvising at a few different points:

• Create a VM and install Debian Stretch 9
• Install the required packages and libraries
• Get the keys and install a Redox toolchain
• Install Rust (nightly), cargo and xargo
• Do a make fetch; make pull on the main repo
• Get a Redox login prompt (x86_64) with make kvm=no vga=no qemu

Mission accomplished! 🎉

Compile the kernel for AArch64

What? Yes indeed! Thanks to @microcolonel’s this can be done (check the above mentioned How-To for detailed steps).Switch to origin/aarch64 branch

Summary:

• Switch to the origin/aarch64 branch
• Update the submodules (kernel and syscall)
• Get the aarch64-elf GNU toolchain
• Get @microcolonel’s modified rust compiler that is using llvm with added toolchain triplet support for the aarch64-unknown-redox
• Compiling a patched version of U-Boot
• Let rustup know about our new AArch64 Rust compiler
• Build the kernel!

make ARCH=aarch64 CROSS_COMPILE=aarch64-elf- PLATFORM=qemu-system-aarch64-virt INSTALLER_FLAGS=”” build/kernel

Building UEFI for HiKey960 from source

Hikey960 currently only supports UEFI based booting using the Tianocore edk2 project. @microcolonel and I are exploring how we can get to the same boot flow by chain-loading u-boot from edk2 but that’s for later.

Code Preparation

Note: I only recently discovered that you can find pre-built binary UEFI images from Linaro but here are the steps I followed ot build from source for those who want to learn about it!

Create a working directory, let’s call it makeUEFIand get all the repositories needed in there:

It is important to get the current working branches in order to compile successfully. You may need the openssl-dev package as well, so keep that in mind.

git clone https://github.com/ARM-software/arm-trusted-firmware -b integration
git clone https://github.com/96boards-hikey/edk2 -b testing/hikey960_v2.5
git clone https://github.com/96boards-hikey/OpenPlatformPkg -b testing/hikey960_v1.3.4
git clone https://github.com/96boards-hikey/l-loader -b testing/hikey960_v1.2
git clone https://git.linaro.org/uefi/uefi-tools
git clone https://github.com/96boards-hikey/atf-fastboot

Let’s build!

Note: You may be able to find lot of the following instructions online, especially in the HiKey960 GitHub official documentation, as well a few Japanese blogs, where they are installing Debian on the HiKey. The problem is that in all of those sources, there’s always an error that stops you from following the steps successfully.

It feels almost like it’s an upside-down documentation (first tinkering with code and then trying to remember the steps involved!). By following the steps below you can be sure that everything is meticulously tested :)

Save the following bash script and execute it on your ${BUILD_PATH}

#!/bin/bash
# Install UEFI from source on HiKey960

export BUILD_PATH=`pwd`

cd ${BUILD_PATH}/edk2
ln -s ../OpenPlatformPkg 

# for the v1 of Hikey960, remove the following line from the tools/platform.config
# BUILDFLAGS=-DSERIAL_BASE=0xFDF05000

BUILD_OPTION=DEBUG

export AARCH64_TOOLCHAIN=GCC5
export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools
export EDK2_DIR=${BUILD_PATH}/edk2

EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}

cd ${EDK2_DIR}

# Build UEFI & ARM Trust Firmware
# Again, please use gcc-5.3 to build

${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey960

# Generate l-loader.bin

cd ${BUILD_PATH}/l-loader
ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin
ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin
ln -sf ${EDK2_OUTPUT_DIR}/FV/BL33_AP_UEFI.fd

python gen_loader_hikey960.py -o l-loader.bin — img_bl1=bl1.bin — 
img_ns_bl1u=BL33_AP_UEFI.fd

# Generate partition table (You can download from net directly)
# See generate_ptable.sh to config your own ptable

PTABLE=linux-32g SECTOR_SIZE=4096 SGDISK=./sgdisk bash -x generate_ptable.sh

Serial and flashing

To flash the loader you need to have the board in Recovery Mode (look at the following table for reference):

Unfortunately you can’t access the Boot Screen usingminicom. For that purpose you can try ser2net(or alternatively picocombut I had more success with the former).

sudo apt-get install ser2net

Append the line for serial-over-USB in the config file etc/ser2net.conf

2001:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner

• Boot UEFI in recovery mode. Create a connection with your Serial to USB cable (usually on either/dev/ttyUSB0{1} . You can always check this by runningdmesg before and after inserting the Serial to USB table.
• Install the HiKey960 recovery tools:

git clone https://github.com/96boards-hikey/tools-images-hikey960

cd tools-images-hikey960

# Ensure that the l-loader is set up 
# on the correct addresss

cat config

./hisi-sec_usb_xloader.img 0x00020000
./hisi-sec_uce_boot.img 0x6A908000
./recovery.bin 0x1AC00000

• If you are using a Debian-based distribution remove the modemmanager package. This package may cause hikey_idt tool to fail.
  sudo apt-get purge modemmanager
• Run the command to download l-loader.bin into HiKey960, using the right USB port:
  sudo ./hikey_idt -c config -p /dev/ttyUSB0{1}
• Now that UEFI is running on the Recovery Mode it’s time to flash update the images!

# Flash the images onto HiKey960
sudo fastboot flash ptable prm_ptable.img
sudo fastboot flash xloader hisi-sec_xloader.img
sudo fastboot flash fastboot l-loader.bin
sudo fastboot flash fip fip.bin
sudo fastboot flash boot boot.img
sudo fastboot flash cache cache.img
sudo fastboot flash system system.img
sudo fastboot flash userdata userdata.img

• Boot UEFI in Fastboot mode (see above)
• Runtelnet localhost 2001
• Using the Esc key, the boot manager is loaded. From there you can access UEFI Console, Android Fastboot or Grub!

Good job!!! 🥂🎇

Using U-Boot as an EFI payload

Das U-Boot is not just *another bootloader. *It’s one of the most used bootloaders in the embedded world. A brain child of Wolfgang Denk, it has been adopted by many developers and companies and they all contribute to its source base.

For a bootloader to be successful around a variety of processors and architectures, a method of configuring it is necessary. This is happening during compile time (as with the Linux kernel). This technique is significantly reducing the complexity of the bootloader.

In the case of Das U-Boot, this configuration is driven by a single header file specific to the target platform and a few soft links in the source tree, that depending on the architecture, target board, etc select the required sub-directories.

The first step of configuring Das U-Boot for a specific platform/board/architecture is done by issuing:

make <platform>_config

Configuration options are selected using macros in the form of CONFIG_XXXX. Configuration settings are selected using macros in the form of CFG_XXXX. In general, configuration options (CONFIG_XXX) are user configurable and enable specific U-Boot operational features. Configuration settings (CFG_XXX) are usually hardware specific and require detailed knowledge of the underlying processor and/or hardware platform.

Board-specific U-Boot configuration is driven by a header file dedicated to that specific platform that contains configuration options and settings appropriate for the underlying platform. The U-Boot source tree includes a directory where these board-specific configuration header files reside, namely ../include/configsdirectory where you can change anything suitable for the board you are using/porting.

For a more insider’s approach have a look at the great paper UEFI on Top of U-Boot, written from SUSE’s Andreas Färber and Alexander Graf!

Note: If I have some extra time this month, I will try to attempt porting U-Boot for the HiKey960 although I can’ t promise anything :)

Keep tuned for my approach and the issues I had on my way; my next article is out next week!

Fun Stuff

Would you like to learn more about Operating Systems, their internals and do some small (but exciting) experiments on Raspberry Pi?

I have two great suggestions for you. One is a (quite old) lab from the University of Cambridge in U.K., namely Operating Systems Development.

The other one, is from the University of Stanford and it’s very recent and relevant Writing an OS in Rust!

I hope that you can get a bit more insight from those and enjoy as much as I did.

Next steps

To conclude, I am trying to get into the habit of writing more often blogs but it feels currently that my time is better spent experimenting and keeping everybody updated with a longer (and hopefully more detailed) monthly blog entry!

Having a regular weekly chat with @microcolonel is very helpful. His kind, patient and helpful approach gives me a lot to think about, experiment and learn.

The community of Redox is very engaging and active and its future looks very bright to me!

Introduction

This is a description on how to cross compile[1] a custom Linux kernel for the Raspberry Pi 3B including kernel debugging and memory leak investigation configurations.

[1] Using ahost Fedora 28 to a guestRaspberry Pi system; instructions may differ depending on your OS, for example for Debian-based OS’s it can be something similar to gcc-arm-linux-gnueabihf

Setting Up

Getting the kernel

First thing to do while reading this, is to start downloading the kernel repo; It can take some time.

git clone --depth=1 https://github.com/raspberrypi/linux/

Current branch at the time of writing (July 2018) is the rpi-4.14.y.

Using an old .config

If there’s already a known working kernel configuration file on hand from the OS then it’s advised to use it. It usually is on the location /proc/config.gz. For the file to exist, the option Kernel .config support should be enabled in the kernel. This is the case on the current Raspberry Pi 3 and in case you don’t see the file there then do a sudo modprobe configs and the file will magically appear in the right place.

# On the host
KERNEL=kernel7
# Transfer your old file from your Pi via scp
zcat /proc/config.gz > .config
# Clean any old config files
make mrproper
# make the kernel aware of using an old configuration
make ARCH=arm CROSS_COMPILE=arm-linux-gnu- oldconfig
# and setup with new options; look on the next section
make ARCH=arm CROSS_COMPILE=arm-linux-gnu- menuconfig

Detailed debug info configuration

As a reference here’s the (missing) required configuration for a debug and memory leak detection kernel. For more information consider reading the Linux Kernel Documentation. This is for reference only, the .config file shouldn’t be manually edited as there are dependencies between the options; that may result in a non/malfunctioning kernel.

# Note: The commented options are important but they were already enabled
# = CONFIG_PRINTK_TIME=y
# = CONFIG_DEBUG_KERNEL=y
# = CONFIG_KALLSYMS=y
# = CONFIG_KGDB=y
# = CONFIG_KGDB_SERIAL_CONSOLE=y
# = CONFIG_KGDB_KDB=y
# = CONFIG_PROC_FS=y
# = CONFIG_MAGIC_SYSRQ = y
# = CONFIG_SYSFS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PREEMPT=y # CLASH WITH VOLUNTAR?Y
CONFIG_KDB_KEYBOARD=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_KCORE=y
CONFIG_CRASH_DUMP=y
CONFIG_DEBUG_INFO=y
CONFIG_KEXEC=y
CONFIG_SLUB_DEBUG_ON=y
CONFIG_SLUB_STATS=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=4096
CONFIG_DEBUG_KMEMLEAK_TEST=m

Making the kernel

Fire it and grab a cup of tea while waiting for the compilation!

make -j6 ARCH=arm CROSS_COMPILE=arm-linux-gnu- zImage modules dtbs

Debug Notes

Add to the /boot/cmdline.txtthe following, whereuser_debug=Nis one of the following:

1 — undefine instruction events
2 — system calls
4 — invalid data aborts
8 — SIGSEGV faults
16 — SIGBUS faults

Installing onto the SD Card

To identify the SD run lsblk before and after the SD insertion. You ‘re going to get two partitions: p1 should be the boot partition, while p2 the rootfs. Now create two folders in oder to mount the fs, for example:

mkdir -p mnt/bootfs
mkdir mnt/rootfs

Mount and install the modules:

sudo mount /dev/xxxp1 mnt/bootfs
sudo mount /dev/xxxp2 mnt/rootfs

sudo make ARCH=arm CROSS_COMPILE=arm-linux-gnu- INSTALL_MOD_PATH=mnt/rootfs modules_install

After that you need to copy the kernel and device tree blobs onto the SD card:

# Run all that as root
cp mnt/bootfs/$KERNEL.img mnt/bootfs/$KERNEL-backup.img
cp arch/arm/boot/zImage mnt/bootfs/$KERNEL.img
cp arch/arm/boot/dts/*.dtb mnt/bootfs/
cp arch/arm/boot/dts/overlays/*.dtb* mnt/bootfs/overlays/
cp arch/arm/boot/dts/overlays/README mnt/bootfs/overlays/
umount mnt/bootfs
umount mnt/rootfs

Debugging

This is just a reference and some things to try using the compiled kernel to get more debugging information. I am writing a new article that is addressing the issue in more detail. Stay tuned!

Memory leaks

# Using kernel memory leak debugging
# sudo mount -t debugfs nodev /sys/kernel/debug # superfluous — already mounted
sudo bash -c “echo scan > /sys/kernel/debug/kmemleak”
sudo cat /sys/kernel/debug/kmemleak # Repeat to see updated info

# IF the `echo scan…` part above *fails*, check /var/log/kern.log
# What I saw: “Kernel memory leak detector disabled”,
# “Early log buffer exceeded (####), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE”

# I increased CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE and rebuilt/reinstalled the kernel

# Another handy command:
sudo slabtop -sc

Oops and bugs

If the kernel is compiled with the option CONFIG_KALLSYMS then the dump is usable as it is. The most important information to keep is the EIP line ignoring the 0010:. By looking at the uncompressed kernel (vmlinux and not zImage or vmlinuz) with nm vmlinux | sort | less one can extract the name list, match it against the EIP from the kernel crash and look up the kernel function that contains the offending address.

Note: The address can’t be matched exactly (so it cant’ be grepped) but it’s a good starting point as to discover the location of the call.

Alternatively, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the kernel with -g; edit arch/arm/Makefile appropriately, then do a make clean. You’ll also need to enable CONFIG_PROC_FS (via make config).

After you’ve rebooted with the new kernel, launch gdb vmlinux /proc/kcore. You can now use all the usual gdb commands. The command to look up the point where your system crashed is l *0xXXXXXXXX. (Replace the XXXes with the EIP value.)

gdb’ing a non-running kernel currently fails because gdb (wrongly) disregards the starting offset for which the kernel is compiled.

Troubleshooting

Can’t load kernel modules

Check which modules are loading through the conf file emacs -nw /etc/modules-load.d/*.conf (try commenting a few out) and run sudo systemctl status systemd-modules-load.service which should give more detailed information on what is failing.

Cannot find wifi card / No Internet

It seems a bit weird as sometimes after a kernel installation the internet installation seems to fail. I suggest that before installing the modified kernel do a sudo raspi-update to get the current firmware blobs.

Useful articles

Many of the information above has been compiled through a lot of experimentation, crashed systems, dumped cores and a lot of reburned SD cards. Thanks all the authors for their Free and Open Source approach.

Linux Kernel Admin Guide
Debugging the linux kernel
The kernel newbie debugging
Debug kernel space memory leak
Trace and debug the linux kernel
Newbie corner kernel
Kernel debugging tips

Everybody knows that Rust is the most beloved language for developers since it appeared! Same goes for Raspberry Pi, the small but mighty computer, that costs just £30 but brings a whole awesomeness on board (I wish Broadcom Engineers were a bit more open with their design and less lazy to implement the whole ARM GIC; but let’s keep this for another time).

Here is a small walkthrough, on how to use Mac OSx, Linux or even Windows (hey not tested but I am sure you can make it work, the tools are the same) to compile your Rust marvellousness and run the binary directly on the Raspberry Pi (2/3/3+).

You can find a few different tutorials describing this process but almost never for Mac OSx.

My solution is very simple: use Vagrant! If you haven’t heard about it is an open-source software product for building and maintaining portable virtual software development environments e.g. for VirtualBox and so on. It really simplifies software configuration management of virtualizations and makes you life sooo much easier and productive 🤗

If you have a Linux based bistro, then you can just skip the steps 1–2.

Preparation 👈🏼

The simple steps for achieving all the above are the following (the first two steps assume Mac OSx; for Windows users you can do something similar but Google on how to install the tools described):

1. Install Virtualbox on your machine and install Vagrant

brew cask install virtualbox
brew cask install vagrant
brew cask install vagrant-manager

2. Add the Vagrant box you want to use, start it and ssh into it. We’ll use Debian Stretch for the following example

cd ~/workspace/rust

vagrant init debian/stretch64
vagrant up
vagrant ssh
# you can quit the machine with 'vagrant halt'

4. (If you have arrived here from the steps above, yes that was it. Now you ‘re running a Debian, straight into your Mac OSx at the speed of light 😮)

It’s a good idea to update to the current package versions. Do that and then install Rust (nightly 🌌 is recommended)

sudo apt update
sudo apt upgrade

# you may need to 'sudo apt install curl' as well
curl https://sh.rustup.rs -sSf | sh

# Choose 2, Enter, nightly, y. Confirm and press 1 to install.

Now you should be welcomed with

Rust is installed now. Great! 🎉

5. Install the GNU ARM toolchain and their respective Rust crates

source $HOME/.cargo/env

sudo apt-get install -qq gcc-arm-linux-gnueabihf
rustup target add armv7-unknown-linux-gnueabihf

6. Configure Cargo for cross-compilation

mkdir -p ~/.cargo

# > should not be included when pasting

cat >>~/.cargo/config <<EOF
> [target.armv7-unknown-linux-gnueabihf]
> linker = "arm-linux-gnueabihf-gcc"
> EOF

7. That was it! Run a simple test

cargo new --bin hello 
cd hello 
cargo build --target=armv7-unknown-linux-gnueabihf

which should happily create an ARMv7 binary[1]! To be sure

[1] For the difference between ARM7 and ARMv7 check here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13706.html Thanks @LulzCop for spotting my mistake :)

file target/armv7-unknown-linux-gnueabihf/debug/hello

vagrant@stretch:~/hello$ target/armv7-unknown-linux-gnueabihf/debug/hello: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=39cfb5d9c8cda29ecac841120a2ef9c170f84399, not stripped

# you can scp and run the executable on the ARM to finalise your test!

Hurray! Now you can cross-compile Rust for ARM-based devices from the comfort of your own OS🤩

As always ping me if you have any questions and please comment in case something doesn’t work as expected!

…and here we go!

All excited. A first calendar entry to describe my attempt on arm64 support in Redox OS.

Specifically, looking into the Raspberry Pi2/3b/3+(all of them having a Cortex-A53 ARMv8 64-bit microprocessor, although for all my experiments I am going to use the Raspberry Pi 3b.

Yesterday, I had my (@wizofe) first meeting in Cambridge with @microcolonel! Very very inspiring, got many ideas and motivation. He reminded me that the first and most important thing I fell in love with Open Source is its people :)

Discussion Points

Everything started with a personal introduction, background and motivation reasons that we both participate in this project. It’s very important to note that we don’t want it to be a one-off thing but definitely the start of a longer support and experimentation with OS support and ARM.

Redox boot flow on AArch64

Some of the points discussed:

• boot
• debug
• MMU setup
• TLS
• syscalls

The current work by @microcolonel, is happening on the realms of qemu-system-aarch64 platform. But what should I need to put my attention, when porting to the RPi3? Here are the most importants bits:

• Typical AArch64 exception level transitions post reset: EL3 -> EL2 -> EL1
• Setting up a buildable u-boot (preferably the u-boot mainline) for RPi3
• Setting up a BOOTP/TFTP server on the same subnet as the RPi3
• Packaging the redox kernel binary as a (fake) Linux binary using u-boot’s mkimage tool
• Obtaining an FDT blob for the RPi3 (Linux’s DTB can be used for this). In hindsight, u-boot might be able to provide this too (u-boot’s own generate )
• Serving the packaged redox kernel binary as well as the FDT blob to u-boot via BOOT/TFTP
• Statically expressing a suitable PL011 UART’s physical base address within Redox as an initial debug console

Note: I’ve already completed (as shown) two important steps, which I am going to describe on my next blog post (to keep you excited ;-)

Challenges with recursive paging for AArch64

@microcolonel is very fond of recursive paging. He seems to successfully to make it work on qemu and it seems that it may be possible in silicon as well. This is for 48-bit Virtual Addresses with 4 levels of translation.

As AArch64 has separate descriptors for page tables and pages which means that in order for recursive paging to work there must not be any disjoint bit fields in the two descriptor types. This is the case today but it is not clear if this will remain in the future.

The problem is that if recursive paging doesn’t work on the physical implementation that may time much longer than expected to port for the RPi3. Another point, is that as opposed to x86_64, AArch64 has a separate translation scheme for user-space and kernel space. So while x86_64 has a single cr3 register containing the base address of the translation tables, AArch64 has two registers, ttbr_el0 for user-space and ttbr_el1 for the kernel. In this realm, there has been @microcolonel’s work to extend the paging schemes in Redox to cope with this.

TLS, Syscalls and Device Drivers

The Redox kernel’s reliance on Rust’s #[thread_local] attribute results in llvm generating references to the tpidr_el0 register. On AArch64 tpidr_el0 is supposed to contain the user-space TLS region’s base address. This is separate from tpidr_el1 which is supposted to contain the kernel-space TLS region’s base address.

To fix this, @microcolonel has modified llvm such that the use of a ‘kernel’ code-model and an aarch64-unknown-redox target results in the emission og tpidr_el1. TLS support is underway at present.

Device drivers and FDT

For the device driver operation using fdt it’s very important to note the following:

• It will be important to create a registry of all the device drivers present
• All device drivers will need to implement a trait that requires publishing of a device-tree compatible string property
• As such, init code can then match the compatible string with the tree of nodes in the device tree in order to match drivers to their respective data elements in the tree

Availability of @microcolonel’s code base

As he still expects his employer’s open source contribution approval there are still many steps to be done to port Redox OS.

The structure of the code to be published was also discussed. At present @microcolonel’s work is a set of patches to the following repositories:

• Top level redox checkout (build glue etc)
• Redox kernel submodule (core AArch64 support)
• Redox syscall’s submodule (AArch64 syscall support)
• Redox’s rust submodule (TLS support, redox toolchain triplet support)

Possible ways to manage the publishing of this code were also discussed. One way is to create AArch64 branches for all of the above and push them out to the redox github. This is TBD with @jackpot51.

Feature parity with x86_64

It’s very important to stay aligned with the current x86_64 port and for that reason the following work is important to be under way:

• Syscall implementation
• Context switch support
• kmain -> init invocation
• Filesystem with apps
• Framebuffer driver
• Multi-core support
• (…) (to be filled with a whole list of the current x86_64 features)

Attaining feature parity would be the first concrete milestone for the AArch64 port as a whole.

My next steps

As a result of the discussion and mentoring, the following steps were decided for the future:

• Get to a point where u-boot can be built from source and installed on the RPi3
• Figure out the UART base and verify that the UART’s data register can be written to from the u-boot CLI (which should provoke an immediate appearance of characters on the CLI)
• Setup a flow using BOOTP/DHCP and u-bootthat allows Redox kernels and DTBs to be sent to u-boot over Ethernet
• Once @microcolonel’s code has been published, start by hacking in the UART base address and a DTB blob
• Aim to reach kstart with println output up and running.

Next steps for @microcolonel

• Complete TLS support
• Get Board and CPU identification and display going via DTB probes
• Verify kstart entry on silicon. @microcolonel means to use the Lemaker Hikey620 Linaro 96Board for this. It’s a Cortex-A53 based board just like the RPi3. The idea is to quickly check if recursive paging on silicon is OK. This can make @wizofe’s like a lot rosier. :)
• Make the UART base address retrieval dynamic via DTB (as opposed to the static fixed address used at present which isn’t portable)
• Get init invocation from kmain going
• Implement necessary device driver identification traits and registry
• Implement GIC and timer drivers (Red Flag for RPi3 here, as it has no implementation of GIC but rather a closed proprietary approach)
• Focus on user-land bring-up

Future work

If we could pick up the most important plan for the future of Redox that would be a roadmap!

Some of the critical items that should be discussed:

• Suitable tests and Continuous integration (perhaps with Jenkins)
• A pathway to run Linux applications under Redox. FreeBSD’s linuxulator (system call translator) would be one way to do this. This would make complex applications such as firefox etc usable until native solutions become available in the longer term.
• Self hosted development. Having redox bootable on a couple of popular laptops with a focus on feature fullness will go a great way in terms of perception. System76 dual boot with Pop_OS! ? ;)
• A strategy to support hardware assisted virtualization.

Thanks for reading! Hope to see you next time here. For any questions feel free to message me here! Many many insights are taken from @microcolonel’s very detailed summary; The following part of the blog is my own experimentation and exploration on the discussed matters!

I did some research and I found out that the drivers are already part of the kernel, so there’s no need to add external developmental Intel HD drivers.

In the end the solution was very simple: to add the following file/contents to the system and reboot. Magic!

Case: Thinkpad T450
Video Driver: Intel HD 550
Problem: Screen tearing when scrolling on an HD screen

Solution:

• Create a new file, namely /etc/X11/xorg.conf.d/20-intel.conf
• Add this to the file

Section “Device”
 Identifier “Intel Graphics”
 Driver “intel”
 Option “TearFree” “true”
EndSection

• That’s it, now reboot and enjoy your new HD experience!

This is a quick and sexy guide on installing Fedora 27 on a 2014 15' Macbook Pro. Many people are intimidated by Linux and partitioning hard drives but in all honesty there’s nothing to be scared (although to be fair it wasn’t my first time installing Linux; I still remember the moment I installed it on my iPod 120Gb device.

Yes, fellow reader, you read correctly that’s not an iPad but a 10 years old iPod with 240Gb hard drive, at times you didn’t have to pay an extra £100 tupgrade from 32 to 64Gb space.

Approach this as a curated list of links and genius ideas around the World Wide Web. Link or add your own on the comments.

1 — macOS, getting the required files

First step is to use your browser and GetFedora. I opted for the latest version (currently 27). A fancy script is happy to recognise your macOS and offer you the “Fedora Media Writer”. This is a tool for downloading the required Fedora image file (about 1.5Gb), while also used to build a USB Live distro.

While waiting for the download, fire diskutil and create a new 15–20Gb partition on your hard drive. If you have High Sierra you’ll need to choose the option ‘Partition’ (and confirm that you’re sure you need this) and create an extra FAT32 (the file system doesn’t matter at this stage as you’re going to re-format later anyway).

2— WiFi

As there’s no out of the box support for the Broadcom 4360 WiFi network adapter you need to connect to Ethernet or (if you’ve no spare Thunderbolt to Ethernet connector) use your mobile phone in USB Tethering mode. Of course that depends on the phone maker but it should be somewhere around Settings, Data/Internet. Don’t forget that for this option you shoulnd’t enable MPT mode (in my case it was the camera mode).

Try out if your connection is up:

[wizofe@earthsea ~]$ ping www.google.com

PING www.google.com(ham11s01-in-x04.1e100.net (2a00:1450:4005:800::2004)) 56 data bytes
64 bytes from ham11s01-in-x04.1e100.net (2a00:1450:4005:800::2004): icmp_seq=1 ttl=53 time=57.3 ms

Whoot. We ‘re online.

Now you ‘re ready to install the Broadcom 4360 drivers. Here’s a tutorial from jamespamplin Github repo.

3 — Graphic Card

I am going to talk about my graphic card (NVIDIA GK107M, or as usually known GT 750M). If you have a different card then please follow the instructions but try to google which is your required drivers.

Follow this guide to install the propietary video drivers from nVidia and disable the open source Nouveau. In my case, I decided to stay open source as I am using Linux for developing purposes (if I need Video and Photo Editing, I switch to macOS anyway ;))

Fedora 27/26/25 nVidia Drivers Install Guide

4 — Larger console font (for the virtual terminal)

With the high dpi Retina screen, the Visual Console has really tiny font size and it’s impossible to work in. I am tooking about the full screen terminal and not the GNOME console. You can reach it by using the combination Ctrl-Alt-F[2–6].

Here’s an except from Martin’s Blog:

First, I generated a custom font file from one of the TTF fonts installed on my system (in this case from Google Noto):

sudo mkdir /boot/grub2/fonts
sudo grub2-mkfont -s 36 -o /boot/grub2/fonts/NotoSansRegular36.pf2 \
 /usr/share/fonts/google-noto/NotoSans-Regular.ttf

This font can now be used in /etc/default/grub:

GRUB_TIMEOUT=5 
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" 
GRUB_DEFAULT=saved 
GRUB_DISABLE_SUBMENU=true 
GRUB_TERMINAL_OUTPUT="gfxterm" 
GRUB_CMDLINE_LINUX="..." 
GRUB_DISABLE_RECOVERY="true" 
GRUB_FONT="/boot/grub2/fonts/NotoSansRegular36.pf2"

Basically, I added the GRUB_FONT entry which points to the font to use. In addition, I had to change the GRUB_TERMINAL_OUTPUT from console to gfxterm.

Note: The remaining entries must remain as they are! Only edit the two variables.

Finally, the GRUB configuration can be regenerated.

 # EFI:
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

To increase the font size for the Linux console (Ctrl+Alt+F[2–8]), first install the terminus fonts:

sudo dnf install terminus-fonts-console

Now, change to a TTY and use the setfont command to load one of the fonts. You will find them in /usr/lib/kbd/consolefonts/. For me, the ter-m32n font works quite nicely:

sudo setfont ter-m32n

To make this font the default console font, edit /etc/vconsole.conf and adjust the FONT entry:

KEYMAP="gb" 
FONT="ter-m32n"

5 — Upgrade Fedora

Simply run:

dnf --update

After this update the wifi is going to break again but the only thing you need to do is run:

akmods --force

and this will reload the required kernel modules.

6 — Setting up vim

Two of my favourite plugins for Vim are Vim Sensible and SpaceVim. To install sensible you need the Pathogen plugin manager. Pretty easy to install:

mkdir -p ~/.vim/autoload ~/.vim/bundle && \
curl -LSso ~/.vim/autoload/pathogen.vim https://tpo.pe/pathogen.vim

now create a .vimrc file in your home folder (preferably with …vi!) and add the following (input with ‘i’ and close and save with :wq)

execute pathogen#infect()
syntax on
filetype plugin indent on

now to install ‘sensible’ run:

cd ~/.vim/bundle
git clone git://github.com/tpope/vim-sensible.git

In addition I will link my .vimrc file to my github so you can get some ideas of my setup. Feel free to build on it, although I *love* the theme of vim sensible!

• airline (for the status line)
• w0rp/ale (for on the fly lint checking)
• plugged (plugin manager)
• goyo (for distraction free writing)
• lightline (for status line sugarcoating)
• tcomment_vim (gcc for commenting a line; sweet)
• easymotion (to move around with ease)

Here is a nice blog with definitely the most useful vim plugins ever:

http://sherifsoliman.com/2016/05/30/favorite-vim-plugins

If you are interested on how to use vim8 as an IDE for coding have a look at this really cool article as well. As a reference I am using the following plugins:

Use Vim as a Python IDE

7 —Linux basics

It is out of the scope of the guide to provide a Linux tutorial although if you are really starting now, have a look at this nice and simple introduction to Fedora Linux by David Farning:

DavidFarning/fedorafaqBasics - Fedora Project Wiki

8 —Future

Future planned articles are an Introduction to Linux device drivers, experimenting with microcontrollers and sensors (Atmel Mega AVR, Arduino, Raspberry Pi).

I am also writing a re-make of the Cambridge Computer Lab tutorial of how to make a simple Operating System (in Assembly Language) using Raspberry Pi 3.

Hope to see you again soon and feel free to drop me a line for any ideas, additions or kudos ;)