The ARMv9 ISA, And What It Can Do For You

May 10, 2021 by Maya Posch 38 Comments

The number of distinct ARM Instruction Set Architectures (ISA) versions has slowly increased, with Arm adding a new version every few years. The oldest ISA version in common use today is ARMv6, with the ARMv6 ISA (ARM11) found in the original Raspberry Pi SBC and Raspberry Pi Zero (BCM2835). The ARMv6 ISA was introduced in 2002, followed by ARMv7 in 2005 (start of Cortex-A series) and ARMv8 in 2011. The latter was notable for adding 64-bit support.

With ARMv7 being the first of the Cortex cores, and ARMv8 adding 64-bit support in the form of AArch64, what notable features does ARMv9 bring to the table? As announced earlier this year, ARMv9’s focus appears to be on adding a whole host of features that should improve vector processing (vector extensions, or SVE) as well as digital signal processing (DSP) and security, with its Confidential Compute Architecture (CCA).

In addition to this, ARMv9 also includes all of the features that were added with ARMv8.1, v8.2, v8.3 and so on. In essence, this makes an ARMv9-based processor theoretically capable of going toe-to-toe with the best that Intel and AMD have to offer.

Continue reading “The ARMv9 ISA, And What It Can Do For You” →

Debug ARM Virtually

April 23, 2021 by Al Williams 8 Comments

With the advent of super powerful desktop computers, many developers make use of some sort of virtual or psuedo-virtual machines (VM). We run Windows in a VM and do kernel development in a VM, too. If you are emulating the same kind of computer you are on then the process is simpler, but it is possible to run, say, ARM code on an x86 (or vice versa) but with possibly slower performance than running natively. QEMU is probably the best-known program that allows a CPU to run code targeting a different CPU, but — by default — it targets desktop, laptop, and server-class machines, not tiny embedded boards. That’s where xPack QEMU Arm comes in. It allows you to run and debug embedded Cortex-M devices in an emulated environment on a host computer.

The tool supports boards like the Maple — which means it should support bluepill, along with popular boards such as the Nucleo, some discovery boards, and several from Olimex. They have plans to support several popular boards from TI, Freescale, and others, but no word on when that will happen. You can see a decidedly simple video example from [EmbeddedCraft] of blinking a virtual LED in the video below, although you might like to mute your audio before playing it.

Continue reading “Debug ARM Virtually” →

Scratch-Built Robot Arm Looks Like Something Off The Factory Floor

April 10, 2021 by Dan Maloney 13 Comments

[Jeremy Fielding] is rightly impressed with the power and precision of industrial robot arms. The big arms that you see welding cars on assembly lines and the like are engineering feats in their own right, which is why his leap into scratch-building one in the home shop promises to be quite an adventure, and one we’re eager to follow.

From the look of the video below, [Jeremy]’s arm is already substantially complete, so it seems like he’ll be releasing videos that detail how he got to the point where this impressively large and powerful arm took over so much of his shop. He’s not fooling around here — this is a seven-axis articulated arm built from aluminum and powered by AC servos. [Jeremy] allows that some of the structural parts are still 3D-printed prototypes that he’s using to finalize the design before committing to cutting metal, a wise move as he notes that most of the metalworking skills he needs to complete the build are still fairly new to him. It still looks amazing, and we’re looking forward to the rest of the series to see how he got to this point.

We always appreciate [Jeremy]’s enthusiasm and presentation style, and we generally learn a lot from his videos. Whether it’s a CNC table saw, a homebrew dynamometer, or supersonically melting baseballs, his videos are always great to watch.

Continue reading “Scratch-Built Robot Arm Looks Like Something Off The Factory Floor” →

The Long Journey Ahead For Linux On Apple Silicon

March 21, 2021 by Bryan Cockfield 40 Comments

An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.

While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.

While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.

Thanks to [Mark] for the tip!

Porting Firefox To Apple Silicon: Tales From The Trenches

January 22, 2021 by Maya Posch 16 Comments

For any smaller and larger software product that aims to be compatible with Apple’s MacOS, the recent introduction of its ARM-based Apple Silicon processors and MacBooks to go with them came as a bit of a shock. Suddenly one of the major desktop platforms was going to shift processor architectures, and with it likely abandon and change a number of APIs. Over at Mozilla HQ, they assumed that based on past experiences, Apple’s announcement of ‘first Apple Silicon hardware’ would also mean that those systems would be available for sale.

Indeed, one week after the November 10th announcement Apple did in fact do so. By then, Mozilla had worked to ensure that the Firefox codebase could be built for Apple Silicon-based MacOS. Fortunately, through the experiences of running Firefox on Windows-on-ARM, they already had gained a codebase that was compatible with 64-bit ARM. Ultimately, the biggest snag here was the immature Rust language and dependency support for Apple Silicon, which set back the first release.

When it came to the distributing of Firefox on Intel- and ARM-based Macs, the decision was made to package both versions of the application into a so-called Universal Binary. While this pads out the size of the installer, it also means easier distribution and would not affect the built-in updater in Firefox. This also allowed for an easy fix for the Google Widevine DRM module, for which no Apple Silicon version was available at first, allowing the same module for Intel to be used with either Firefox version via the Rosetta 2 binary translator in MacOS (as we covered previously).

After this it was more or less smooth sailing, with some Rosetta 2-based glitches and MacOS Big Sur-related bugs that spoiled some of the fun. What this experience shows is that porting even a big codebase like Firefox to Apple’s new platform is fairly straightforward, with lack of support from toolchains and other dependencies the most likely things that may trip one up.

The Rosetta 2 feature, while helpful, also comes with its share of gotchas as the Firefox developers found out, and of course there is a lot more optimization that can (and should) be done for such a new platform.

The (Probably) Most Thoroughly Commented Linker Script For The SAM D21 MCU

January 19, 2021 by Maya Posch 5 Comments

Linker scripts are one of those things which nobody who does software development really wants to deal with, but like many things in life sometimes they are inevitable to make things work. Although one could keep pretending linker scripts do not exist and let IDEs handle such pesky details, some of us suffer from this unfortunate condition called ‘curiosity’ and just have to know. People like [Thea].

Recently, [Thea] wrote a blog post on exactly what the linker script generated by the Microchip IDE for a Cortex-M-based SAM D21 project does. The result is a nicely annotated overview of the file’s contents, accompanied by links to the Arm and GCC documentation as well as other references where appropriate. The entire linker script (.ld file) can be viewed on GitHub. With the SAM D21 being a popular choice for Arduino and Arduino-compatible board, this article is a good starting point to understanding what a linker script does and how it affects one’s project.

For other (Cortex-M) MCUs this linker script is also useful as a starting point. Especially knowing which sections are required and what changing them affects in the final (ELF) binary and the firmware that is ultimately written to the MCU. We recently covered linker scripts for Cortex-M as well, along with the concept of memory-mapped I/O.

DevTerm Beats Cyberdeck Builders To The Punch

December 8, 2020 by Tom Nardi 45 Comments

What makes a cyberdeck? Looking as though it came from an alternate reality version of the 1980s is a good start, but certainly isn’t required. If you’re really trying to adhere to the cyberpunk ethos, any good deck should be modular enough that it can be easily repaired and upgraded over time. In fact, if it’s not in a constant state of evolution and flux, you’ve probably done something wrong. If you can hit those goals and make it look retro-futuristic at the same time, even better.

Which is why the Clockwork DevTerm is such an interesting device. It ticks off nearly every box that the custom cyberdeck builds we’ve covered over the last couple years have, while at the same time being approachable enough for a more mainstream audience. You won’t need a 3D printer, soldering iron, or hot glue gun to build your own DevTerm. Of course if you do have those tools and the skills to put them to work, then this might be the ideal platform to build on.

With a 65% QWERTY keyboard and widescreen display, the DevTerm looks a lot like early portable computers such as the TRS-80 Model 100. But unlike the machines it draws inspiration from, the display is a 6.8 inch 1280 x 480 IPS panel, and there’s no pokey Intel 8085 chip inside. The $220 USD base model is powered by the Raspberry Pi Compute Module 3, and if you need a little more punch, there are a few higher priced options that slot in a more powerful custom module. Like the Waveshare Pi CM laptop we recently looked at, there’s sadly no support for the newer CM4; but at least the DevTerm is modular enough that it doesn’t seem out of the question that Clockwork could release a new mainboard down the line. Or perhaps somebody in the community will even do it for them.

Speaking of which, the board in the DevTerm has been designed in two pieces so that “EXT Module” side can be swapped out with custom hardware without compromising the core functionality of the system. The stock board comes with extra USB ports, a micro USB UART port for debugging, a CSI camera connector, and an interface for an included thermal printer that slots into a bay on the rear of the computer. Clockwork says they hope the community really runs wild with their own EXT boards, especially since the schematics and relevant design files for the entire system are all going to be put on GitHub and released under the GPL v3.

They say that anything that sounds too good to be true probably is, and if we’re honest, we’re getting a little of that from the DevTerm. An (CPU BLOBs aside!) open hardware portable Linux computer with this kind of modularity is basically a hacker’s dream come true, and thus far the only way to get one was to build it yourself. It’s hard to believe that Clockwork will be able to put something like this out for less than the cost of a cheap laptop without cutting some serious corners somewhere, but we’d absolutely love to be proven wrong when it’s released next year.