At the Linley Processor Conference today, SiFive, the semiconductor company building chips around the Open RISC-V instruction set has announced the availability of a quadcore processor that runs Linux. We’ve seen RISC-V implementations before, and SiFive has already released silicon-based on the RISC-V ISA. These implementations are rather small, though, and this is the first implementation designed for more than simple embedded devices.
This announcement introduces the SiFive U54-MC Coreplex, a true System on Chip that includes four 64-bit CPUs running at 1.5 GHz. This SoC is built with TSMC’s 28 nm process, and fits on a die about 30 mm². Availability will be on a development board sometime in early 2018, and if our expectations match the reality of SiFive’s previous offerings, you’ll be able to buy this Open SoC as a BGA package some months after that.
Continue reading “SiFive Announces RISC-V SoC”
It was never unusual to have a CPU and an FPGA together. After all, each has different strengths and weaknesses. However, newer devices like the Xilinx Zynq have both a CPU and an FPGA in the same package. That means your design has to span hardware, FPGA configurations, and software. [Mitchell Orsucci] was using a Zynq device on a ArtyZ7-20 board and decided he wanted to use Linux to operate the ARM processor and provide user-space tools to interface with the FPGA and reconfigure it dynamically.
This sounds like a big project and it certainly isn’t trivial by any means. However, the Xilinx tools do a lot of the heavy lifting, including setting up the Linux kernel and a suitable root file system. The bulk of [Mitchell’s] work was in developing user space tools for Linux programs to interact with the FPGA hardware. You can see a short video demo below.
Continue reading “The Linux FPGA”
Text-based Linux and Unix systems are easy to manipulate. The way the Unix I/O system works you can always fake keyboard input to another program and intercept its output. The whole system is made to work that way. Graphical X11 programs are another matter, though. Is there a way to control X11 programs like you control text programs? The answer to that question depends on exactly what you want to do, but the general answer is yes.
As usual for Linux and Unix, though, there are many ways to get to that answer. If you really want fine-grained control over programs, some programs offer control via a special mechanism known as D-Bus. This allows programs to expose data and methods that other programs can use. In a perfect world your target program will use D-Bus but that is now always the case. So today we’ll look more for control of arbitrary programs.
There are several programs that can control X windows in some way or another. There’s a tool called xdo that you don’t hear much about. More common is xdotool and I’ll show you an example of that. Also, wmctrl can perform some similar functions. There’s also autokey which is a subset of the popular Windows program AutoHotKey.
Continue reading “Linux Fu: X Command”
There was a time when embedded system developers didn’t need to worry about graphics. When you have a PIC processor and two-line LCD, there isn’t much to learn. But if you are deploying Linux-based systems today, graphics are a real possibility. There are many options for doing Linux graphics including Wayland, X11, and frame buffers. Confused? This tutorial can help. The sections on Wayland and Mir are under construction, but that’s probably not what you are going to be using on a typical hacker project for the foreseeable future, anyway.
Of course, even inside those broad categories, you have multiple choices. If you are doing X11, for example, you can go low-level or pick any of a number of high-level libraries.
Continue reading “Linux Graphics Programming”
What can you do with an IR remote? How about anything? Maybe not. We’ll settle for issuing arbitrary commands and controlling tasks on our computer.
The first step in [Fungus]’s hack is straightforward: buy an IR receiver for a buck, plug it into an Arduino, and load up some IR-decoding code. If you haven’t done this before, you owe it to yourself to take some time now. Old IR remotes are very useful, and dead simple, to integrate into your projects.
But here comes the computer-control part. Rather than interpret the codes on the Arduino, the micro just sends them across the USB serial to a laptop. A relatively straightforward X11 program on the (Linux) computer listens for codes and does essentially anything a user with a mouse and keyboard could — that is to say, anything. Press keys, run programs, open webpages, anything. This is great for use with a laptop or desktop, but it’d also be a natural for an embedded Raspberry Pi setup as well.
Hacking the code to do your particular biddings is a simple exercise in monkey-patching. It’s like a minimal, hacked-together, USB version of LIRC, and we like it.
Thanks [CoolerVoid] for the tip!
The old saying is if your data isn’t backed up at least twice, it’s not backed up at all. For those not wise enough to heed this adage, there are a number of options available to you if you wish your data to be recovered. Assuming the drive itself is just corrupted somehow (maybe a malicious attack, maybe a user error) and not damaged beyond physical repair, the first step is to connect the drive to another computer. If that fails, it might be time to break out the computer forensics skills.
[Luis]’s guide is focused on Linux-specific drives and recovery tools, so this isn’t necessarily a general-purpose how-to. That being said, there is a lot of information in this guide such as how to mount the target drive’s partitions, how to set up various timelines, and which of the Linux system’s logs are important for the forensic analysis. This specific example in the guide also goes into detail about noticing which of the recent files had been accessed, what they might have done, and different approaches to piecing the mystery of this corrupted drive together.
[Luis] points out that the world of Linux forensics is much different from that of Windows, but for anyone looking to get started he suggests starting with a clean Linux install and going from there. There are many other avenues of digital forensics, as well; the field has as many avenues of exploration as there are different types of computers.
It is easy to dismiss bash — the typical Linux shell program — as just a command prompt that allows scripting. Bash, however, is a full-blown programming language. I wouldn’t presume to tell you that it is as fast as a compiled C program, but that’s not why it exists. While a lot of people use shell scripts as an analog to a batch file in MSDOS, it can do so much more than that. Contrary to what you might think after a casual glance, it is entirely possible to write scripts that are reliable and robust enough to use in many embedded systems on a Raspberry Pi or similar computer.
I say that because sometimes bash gets a bad reputation. For one thing, it emphasizes ease-of-use. So while it has features that can promote making a robust script, you have to know to turn those features on. Another issue is that a lot of the functionality you’ll use in writing a bash script doesn’t come from bash, it comes from Linux commands (or whatever environment you are using; I’m going to assume some Linux distribution). If those programs do bad things, that isn’t a problem specific to bash.
One other limiting issue to bash is that many people (and I’m one of them) tend to write scripts using constructs that are compatible with older shells. Often times bash can do things better or neater, but we still use the older ways. For example:
Continue reading “Linux Fu: Better Bash Scripting”