AArch64 shared memory synchronization
I’m continuing playing with 64 bit ARM architecture and the next thing I want to try is spinning up multiple CPUs. However before doing that I need to get out of the way the question of synchronizing multiple concurrently running CPUs and that’s what I touch on in this post.
AArch64 memory and paging
In this post I will return to my exploration of 64 bit ARM architecture and will touch on the exciting topic of virtual memory and AArch64 memory model.
Hopefully, by the end of this post I will have an example of how to configure paging in AArch64 and will gather some basic understanding of the relevant concepts and related topics along the way.
U-boot boot script
To wrap up my explorations of U-boot I’d like show how to automatically load a kernel with U-boot on startup.
How U-boot loads Linux kernel
I’m continuing my exploration of how to use U-boot. Last time I covered some basics, this time I will build on that and will dive into a bit more realistic example - how U-boot loads Linux kernel.
Getting started with U-Boot
A lot of time has passed since I posted last time. Old hobby projects were long forgotten and it’s time to start from scratch, but do it right this time (I wonder if that’s the reason I never finish my hobby projects).
In the past posts I covered already EFI, Qemu, Aarch64. I tried to create a simple EFI bootloader and a simplistic Aarch64 kernel from scratch.
I still didn’t quite abandon the idea of playing with virtualization on Aarch64, but creating everything from scratch, as fun as it is, probably going to delay things even further.
So a new me wants to learn and use some of the existing tools and in this post I will cover the most basic things related to U-boot.
Dynamic Memory Allocation Part3
I didn’t post for quite some time. In the previous post I covered buddy allocator. Buddy allocator, while begin a an actually practical algorithm, has it’s limitations.
One obvious limitation is that it allocates memory in multiples of the basic block size. Moreover the multiplier has to be a power of 2. That will lead to some memory wasted if you want to allocate a memory chunk that is not a power of 2 multiple of the basic block size.
Another caveat is the data that we need to maintain for bookkeeping. In the specifc implementation I showed I pre-allocated a page structure for each basic block. This page structure is a bit above 16 bytes in size and the smaller the base block is the more such structures we need. Which increases the overhead of the buddy allocator if we want to allocate small chunks of memory.
So here I’m going to cover another approach to memory allocation that is more efficient when working with smaller object sizes.
I take no creadit for the algorithm itself. This post covers a very simplified version of an algorithm proposed by Jeff Bonwick and described in the The SLAB Allocator paper.
As always the code is available on GitHub.
The pain of infinite loops
I’ve been struggling dealing with various Rust quirks in my hobby projects and some day I had enough, purged all the Rust code and moved to C++, just to hit an expected, but still interesting quirk of C++.
Dynamic Memory Allocation Part2
In the previous post I covered a generic, but rather simplistic approach to dynamic memory allocation. The approach covered there is legitimate, but isn’t particularly fast and I don’t think it gets a lot of practical use.
In this post I’d like to cover a rather interesting algorithm, that on the one hand is not as generic as the one I covered in the previous post, but on the other hand it’s quite often used in practice.
As always the code is available on GitHub.
A curious case of static memory allocation in Rust
In the previous post I covered the binary representation of the Flattened DeviceTree or DeviceTree Blob and was already starting to work on memory management for my hobby project, but I got stuck for quite some time trying to come up with a reasonable way to work with statically allocated memory in Rust.
I don’t think that I found an obviously convincing approach here, but what can you do…
As always, I have some sources related to the post on GitHub, though in this particular post I will be construction a purely hypothetical example, so you will not be able to find the snippets from the post in the repository.
An Introduction to Devicetree specification
Devicetree is a configuration commonly used to describe hardware present in various platforms. In Linux Devicetree is used for ARMs, MIPSes, RISC-V, XTensa and PowerPC (and probably others).
In this post I’m going to cover the problem that Devicetree is trying to solve, briefly touch on the available alternatives and finally show some code for parsing the binary representation of the Devicetree (a. k. a. Flattened Device Tree or DTB).
All the sources are available on GitHub.
An interesting conditional probability problem
Occasionally I read university books on math and comuter science to refresh my memory. At work I mostly use some linear and mixed integer programming solvers and ready function fitting implementation, but I don’t get to actually solve math problems that often. So I find it entertaining to go through the study book problems from time to time.
This post is about one simple problem that I for some reason find quite cool.
AArch64 Interrupt and Exception handling
In the previous post I gave a somewhat badly structured introduction to the priviledge levels model in AArch64. That was a preparation to make explanation of the interrupt handling a little bit easier in this post.
So let’s get started and as always you can find all the sources on GitHub.
AArch64 Exception Levels
I’m continuing my exploration of the AArch64 architecture and this time I will touch on the AArch64 priviledge levels.
Note that AArch64 priviledge model is not exactly the same as the previous iterations of ARM. While there are plenty of similarities, and there is a level of backward compatibility, at the same time, there are some differences as well. So do not assume that things covered here will work the same way for all ARMs.
Finally, I assume that you’re familiar with general GNU Assembler synatax or willing to figure things out as you go. Familiarity with ARM assmebly language will help, though I try to explain all the things I use.
As always the code is available on GitHub.
Dynamic Memory Allocation Part1
In the previous post I mentioned that I implemented simplistic dynamic memory allocator and plugged it into Rust. So I thought I could create an introductionary post into dynamic memory allocation algorithms.
This post will cover a basic algorithm of dynamic memory allocation and some practical aspects that we might consider when implementing dynamic memory allocators as a sort of introduction into the problem (thus Part1).
As always the code is available on GitHub.
Debugging AArch64 using QEMU and GDB
In the previous post I added Rust to the project and since then I was experimenting with parsing DeviceTree, however while doing that I stumbled on a mistery problem.
In this post I will cover the background that lead to the problem, investigations and finally the solution. There isn’t terribly a lot of code related to this post, but nevertheless all the sources are available on GitHub.
Adding a little bit of Rust to AARCH64
In the previous post we managed to make PL011 UART work on my HiKey960. We did that using C, but all the cool guys these days use Rust, so let’s see how we can make it work.
The sources for this post are available on GitHub.
ARMs PL011 UART on HiKey960 board
In the previous post we managed to make PL011 UART controller as emulated by QEMU work. Emulation is a useful tool, but it’s just never going to be perfect. So naturally I wanted to try it on the real hardware and used HiKey960 board that I have and that happen to have a PL011 compatible UART controller.
The sources for this post are available on GitHub.
ARMs PL011 UART
In the previous post we managed to try our simplistic EFI loader on 64-bit ARM in QEMU and on HiKey960 board. Now I want to try to explore the aarch64 architecture a bit further and maybe create something interesting worth loading on the board.
Since the previous post I’ve made a few changes to the EFI loader, you can find them on GitHub. The sources for this post are also available on GitHub, but in a different repository.
UEFI on AARCH64
In the previous post we covered how an EFI application can load another binary in memory. That’s basically what a bootloader does. In this short post I will show that basically the same code will work on a different architecture.
As usual all the sources are available on GitHub.
Loading an ELF image from EFI
Continuing exploring UEFI after some break. Last time I looked at file access, now I’m going to read an ELF file from the file system, load it in memory and transfer control to the ELF image.
As usual all the sources are available on GitHub.
UEFI File access APIs
Continuing exploring UEFI bit by bit. This time I’m going to briefly cover the file access APIs in UEFI. As usual all the sources are available on GitHub, however since the previous post I’ve made a few changes in the repository that this post will not cover.
Recurrence relations and linear algebra
I recently learned that GitHub markdown doesn’t have native support for rendenring math equations. That seemed quite weird, so I figured that I’d try to look at existing alternatives and flex my tex muscle.
In this post I will try to show an end-to-end example of how to solve linear ordinary recurrence relations and give an intro to all the linear algebra required to do that. Some basic understanding of vector spaces and matrices is still required though.
UEFI handles, GUIDs and protocols
Continuing exploring UEFI bit by bit. This time I’ll cover a small part about UEFI handles, GUIDs and protocols. All the sources are available on GitHub.
Getting started with EFI
I’m trying to explore another relatively new are for me: UEFI. When working on student and hobbt project many people tend to start from legacy BIOS or multiboot to boot their hello world kernels.
On the one hand it makes a lot of sense to use the simplest solution possible. On the other hand EFI complexity serves some purpose and with EFI you get a lot of useful tools right out of the box.
With all that in mind let’s try to cook up something with EFI. All the sources are available on GitHub.
FTDI I2C adapter
In the previous post I covered what USB data transfers we need to configure the FTDI MPSSE cable to work in the MPSSE mode. Now with this knowledge we can continue working on the USB-to-I2C bridge for the kernel.
All the sources used in this article are available on GitHub.
FTDI protocol
In the previous post I touched a little bit on Vendor and Product IDs and changed the Vendor and Product IDs on the FTDI MPSSE cable that I got. I used the FTDI userspace library, but since the goal is to make a USB driver for the kernel in the end, we need to understand how the FTDI library calls are mapped to actual USB data transfers. This post covers what I did.
All the sources used in this article are available on GitHub.
FTDI and USB device ID
In a few of the previous articles I was writing a driver for Nintendo Wiichuk. It was an I2C input device and the driver was tested on BeagleBone Black Wireless. However there weren’t a lot of opportunities for me to use a joystick on the board, so the experience is somewhat incomplete.
The driver for Nintendo Wiichuk is not really architecture specific, so I figured that if I was able to connect the joystick to my laptop it would be cool to try it in a game on my laptop. The problem is that I don’t have any exposed I2C connectors, so I want to try to create an USB to I2C adapter. And this article is the first step.
All the sources used in this article are available on GitHub.
Nintendo Wiichuk Joystick
In this short note we will build on top of the previous post and add support for the joystick in our [Nintendo Wiichuck] device.
All the sources used in this article are available on GitHub.
Nintendo Wiichuk interface and input devices
I continue going through Bootlin training materials on embedded systems and Linux Kernel. In the previous post we configured the second I2C controller the BeagleBone Black or BeagleBone Black Wireless and connected the Nintendo Wiichuk device to the board.
In this article I will look a bit deaper into the Nintendo Wiichuk device interface and how can our driver present the device as an input device.
All the sources used in this article are available on GitHub.
Nintendo Wiichuk and I2C
I continue going through Bootlin training materials on embedded systems and Linux Kernel. In the previous post I covered the basics of cross compiling modules for the BeagleBone Black or BeagleBone Black Wireless as well as an brief introduction into Device Tree.
In this article we will properly configure I2C bus on the board, connect our Nintendo Wiichuk device to the board and check that it’s recognized by the board.
Kernel modules, device drivers and Device Tree
I continue going through Bootlin training materials on embedded systems and Linux Kernel. In the previous post I covered the environment setup, so now we should be able to access the board and share files between the board and the host.
In this article I’m going to try to actually create a few simple Linux Kernel modules, build them for the BeagleBone Black or BeagleBone Black Wireless board and test them on the actual hardware.
All the sources used in this article are available on GitHub.
Updating kernel and bootloader on BeagleBone Black Wireless
I continue going through Bootlin training materials on embedded systems and Linux Kernel. In this article I will cover building and updating Linux Kernel and U-Boot on my BeagleBone Black Wireless, but the same instruction should apply for BeagleBone Black.
Eneter U-Boot console on BeagleBone Black Wireless
I’m going through Bootlin training materials on embedded systems and LinuxKernel. In the training materials they use BeagleBoneBlack or [BeagleBonBlackWireless] boards.
This post covers how to connect the board and drop into U-Boot console, as well as hardware required. I’m using BeagleBoneBlackWireless, but the same should apply to BeagleBoneBlack giving that we don’t use any wireless capabilities of the board.
A few notes on Rust borrow checker
A while ago I tried to embrace Rust, but my experience was mostly negative due to various reasons. However the language and toolchain has machured since then and I’m giving it another shot.
One of the features of Rust that makes it different from the other languages is it’s borrow checker. What follows are a few notes about the Rust borrow checker.
GitHub Pages and Jekyll
I’m mostly trying to stay away from any kind of front-end related engineering because I’ve never found it interesting enough to spend a reasonable amount of time to learn it.
That being said, on a subjective level I like the idea of keeping my posts in VCS close to the code, so I started looking at GitHub Pages. What follows is a very brief explanation of what I found with references to other sources.