A Longtime Reader’s Thoughts About Valve and Steamdeck (and What That Means to GNU/Linux)

Posted in DRM, GNU/Linux, Hardware at 5:57 pm by Dr. Roy Schestowitz

Video games fan
Versatility and general-purpose computing through a Trojan horse of sorts?

Summary: Another person’s interpretation of Valve’s strategy and motivations/ambitions

IN OUR Daily Links we continue to post additional news picks regarding last week’s big news from Valve, as noted in yesterday's post. It’s a bit of an ongoing story because additional details are gradually being revealed. In the next batch of Daily Links we’ll include some focus on Arch Linux and the response from Epic, which is a competitor. Microsoft isn’t even commenting. They seem to be somewhat rattled by the whole thing, as it devastates them on multiple fronts at the same time. It also seems like a good uplift for GNU/Linux on desktops and laptops — a frontier long sought by the loudest Free software enthusiasts.

Our reader Daniel sent us some thoughts, which are based partly on his personal experiences (I myself never used Steam and don’t intend to, either) and partly on what he read/saw. Daniel split that into 5 parts, as follows (with mild corrections in the English text as Daniel’s native tongue is Spanish):

1. You say “its [Valve's] successor to efforts like Proton, SteamOS (Debian), and Steam Machines that never quite materialised”.
I’m not sure if you mean “Steam Machines never materialized”, or “[all of that stuff are past efforts that] never materialized”.
The former is mostly right, whereas the latter mostly wrong. The device does use Proton (it’s pretty much alive and well, even without this device), and uses SteamOS (v3, Arch based, as they got away from Debian some time ago).
But this point wasn’t about correcting you (which I believe wasn’t necessary), but about focusing on your mention of the “efforts”. What are they doing these efforts for? It’s just about money?

The part about materialising was about Steam Machines alone. I’m not the first to point this out, as at least 2 more publications did the same. We included them in Daily Links.

The point is, for the uninitiated at least, Valve hoped to work with hardware partners on computers that have the Debian-based SteamOS preinstalled. That never quite happened at the end, perhaps because Steam surveyed the market, in the same way Palm did with “Foleo”.

This time will be different as the strategy is inherently different in a number of ways. Daniel continues:

2. You also say in the article’s summary: “Valve has chosen GNU/Linux for its power, not for its freedom”.
This is a typical interpretation from Free Software activists — and one that can ultimately be generalized in this way: “either they go fully Free software, or they have other interests — different from freedom”.
Of course I agree with that interpretation: Valve does have other interests, most likely reduced to just simply power and money.
But the thing I don’t like about that interpretation is the implicit binary narrative about freedom.
You see, part of the idea behind this thing they’re doing is this: “It’s a PC. You can do with it whatever you do with a PC. We don’t believe in restricting it.”
That is actually huge. I struggle to make people understand their computing devices (mobile phones, modern gaming consoles, smart TVs, and so on) are artificially-limited computers.
That point is actually about freedom.
They even actually say you can install on there stuff from their rivals (like EA or Microsoft), which contradicts the idea of them “simply wanting power and money”.
They clearly want to establish a hegemony. But that hegemony happens to be kinda OK to me (not the DRM part, of course).
My point: is not “simple” what they’re doing, in fact it is complicated, and so it also involves explicit increased degrees of freedom (specially in contrast with what the gaming ecosystem offers to people).
So I’m not so sure about your lecture. I believe freedom is one of the reasons behind the GNU/Linux choice. It’s not a binary choice between power and freedom, nor any other binary choice. And maybe not be exactly the freedom Free Software activists talk about. But it is partly about freedom, and a significant part of it.

Up to a certain point in time Sony did something similar with PS3. That was a very long time ago. Later came Google with Android (wherein freedom is being lessened over time). Valve would not be the first. This is mostly connected to the “general-purpose computing” battle, which is connected to “right to repair” more than Free (as in freedom) software. It’s the idea that people can do as they please with devices that they have purchased and therefore assume they own.

3. Remember also Steam’s history.
At first, it was revolutionary somehow inside the Windows ecosystem, at the cost of DRM.
Before involving GNU/Linux, gaming on Windows was already full of problems that Steam solved.
It was basically the same effect Netflix had on pirating [sic] movies, but for games: by giving comfort to the people by centralizing problem-solving, they got everybody on the boat.
That’s deeply problematic from a Free software point of view. But it is actually a happy event from a people’s experience perspective. People are just ignorant or unaware of the freedom they’re giving away, and so they have no problem with it.
To that point in history, Valve and Netflix are basically the same shit. However, at the gates of Windows 8, Steam declared war on Windows and went to GNU/Linux, even saying that Windows was a disaster for gaming.
Then “Steam for Linux” came out, and from that day on they never stopped pushing GNU/Linux gaming, even when we’re <2% of their user base 10 years later. And they keep working and keep on pushing GNU/Linux, no matter what “the market” says about it. If you also see that you can buy games without DRM and add them to Steam (so, Steam acts then as a CDN and not a DRM provider/encloser), that they allow stuff like sharing games, that they actually added code to drivers and software layers, and that they even make GNU/Linux-first hardware, they’re very far away from Netflix.
Valve has shown ideals. I doubt you or me will share those ideals any day soon. But they’re certainly not a two-bit power and money-hungry bunch of people like Microsoft or Netflix are. This is different.

Steam comes from a person who once worked for Microsoft. So he seems to be aware of how much of a danger they pose; GNU/Linux reduces Microsoft’s control over his company. Recall what Microsoft did to RealPlayer (and Networks).

As Daniel puts it:

4. Microsoft is their enemy, on various fronts. But it is not their only enemy.
With Steamdeck, Valve is also explicit about the goal of opening the door to other people doing hardware like this. It is not about buying their hardware but about changing the relationship people have with devices.
And so this hardware, strangely cheap for the product and at the same time strangely up-to-date, is also a declaration of war on the hardware front.
Valve is no longer a declared enemy of Microsoft and Windows, but WINTEL itself.
The time was perfect for striking a punch to Intel. And also a strong blow to Nintendo and Sony.
And with stuff like “this is a PC” they’re also taking distance from Apple, not just Microsoft: those bastards try to set “PC” as another word for “Windows”, and “Mac” as something different; Valve says otherwise, and not just by wordsmithing but by embracing GNU/Linux.

That’s an excellent point actually. They also embraced KDE and a distro (as base) not many expected to see (like Google picking Gentoo).

About the distro crafted by Valve, Daniel says:

I saw a few videos the day the news went wild, and every time they showed SteamOS v3 it looked very much like Windows 10.

Minute 04:19 here: To be honest, I don’t use KDE and have not used it since some brief 2008 tests, so I don’t know what it looks like these days.
And the same goes for Windows 10 — an OS that I barely touched, exclusively because of job-related tasks.
But if I’m reading this right, they tuned the UI, making it look like Windows 10.
So… add wine/proton over that, and they’re also bringing back LINDOWS from the grave!
I know there were several attempts at something like that: but if Valve publishes the recipe for it, and back it over time with money and work, they’re making a Windows replacement everybody can clone without using Valve’s trademarks. I mean: Dell, HP, Lenovo, or whatever hardware maker can just copy-paste the proper bits of configs to deploy their own brand (an important detail in business world) instead of using “SteamOS”. And of course there will be community forks.
The point being: this is a poisoned dagger against Windows. Valve is really making a Windows killer here, from ALL fronts at the same time (hardware, software, community, and corporate world), and using gaming as vector.
If I’m right about this, we should REALLY let them play their game, at least for a while.

Finally, Daniel says:

With all of this in mind, my conclusion:
Valve certainly does things we don’t like, and most likely that will never change: it’s hard to think of Valve leaving behind DRM and some questionable practices with devs. But they also seem sincere about the consumer’s interests (or at least their experiences), they’ve showed a stronger commitment to GNU/Linux than most other big tech players (specially in gaming), they show a vision (at least compared with players like Microsoft or Apple), and while they seem as pragmatic and money-based as any business, they also insist in pushing costly long-term ideas like a GNU/Linux based SteamOS or PC-based hardware replacing artificially-limited options.
So, Valve is not our enemy. It’s just that they’re not free software activists either: they’re a business. I was about to compare them with Canonical, but I believe the case is different: Canonical is more like hypocrites, Valve is more sincere. Valve is not about GNU/Linux: they’re just embracing it. And in exchange for the power GNU/Linux gives, Valve also gives stuff back. That doesn’t seem like a parasitic relationship to me, even when the thing Valve gives back may not exactly be software freedom.
If Valve ever wins these gaming wars, they will most likely end up being another Mozilla or Canonical. But Valve does not claim to be a Free software activist organization: they’re not even “not for profit” as Mozilla was. And if they win these wars, the gaming world will be completely different, most likely better for GNU/Linux. So I believe that, if we can’t be Valve supporters, we also shouldn’t be too vocal a critics either, as they’re the closest thing we have to a powerful friend in the gaming world: we should let Microsoft try to fight Valve the wrong way, while we find ways to make more freedom around the software Valve already brings to GNU/Linux ecosystem.

We might revisit this subject some other day because no doubt it’s a game-changer, if you pardon the pun…


HP Products Are Faulty and They Try to Censor Evidence of the Defects

Posted in Deception, Hardware at 7:25 am by Dr. Roy Schestowitz

Summary: HP seems to be operating a censorship army in social control media, working to hide evidence of HP products having severe and chronic problems

Over the past hour I’ve not managed to get anything done as my laptop is failing. It’s not an old laptop, either. But this is typical HP!

Minutes ago I posted (though I can barely type): “Avoid HP keyboards or any HP device that has a key on it. Only on HP devices (3 in a row!) I always have keyboard issues. Keys stop working. This flimsy crap is not acceptable! Never again! Never HP!! Now my MAIN laptop. AGAIN.”

Watch what happened next (within a few minutes):


It has gotten worse since. So I wrote (after the latest message above): “Over the past hour I went from 2 defective HP keyboard keys to 3 and now 4. Not even connected keys, quite far apart. This shit is coming apart. #HP now trying to censor me. (!!)”

I will update this post as this blunder progresses. I should note that I never had any such issue with any other brand of laptop (we have 5 laptops working at work, only one is HP).


Using a Single-Board Computer to Monitor IPFS

Posted in Hardware at 10:34 am by Dr. Roy Schestowitz

IPFS lights-based monitoring on self-hosted SBC
IPFS lights-based monitoring on self-hosted SBC (blue is for status, green and red for upstream and downstream payloads)

Summary: IPFS is light and simple enough to run from one’s home, even on a low-voltage machine, and the code below can be used as a baseline for monitoring IPFS activity 24/7

# 2019-04-22
# 2020-11-07

from blinkt import set_pixel, show
from random import randint,random,shuffle,randrange
from time import sleep
import argparse
import signal

def solid(r,g,b,s):
    while True:
        for pixel in range(8):
            set_pixel(pixel, r, g, b)
def random_lights3():
    while True:
        for pixel in range(8):
            r = randint(0, 255)
            g = randint(0, 255)
            b = randint(0, 255)
            set_pixel(pixel, r, g, b)
def random_lights2():
    while True:
        p=sorted(p, key=lambda x: random())
        for pixel in p:
            r = randrange(0, 255, 16)
            g = randrange(0, 255, 16)
            b = randrange(0, 255, 16)
            set_pixel(pixel, r, g, b)
def random_lights1():
    while True:
        p=sorted(p, key=lambda x: random())
        for pixel in p:
            r = randrange(0, 255, 8)
            g = randrange(0, 255, 8)
            b = randrange(0, 255, 8)
            set_pixel(pixel, r, g, b)
def spacer(r,g,b,seconds):
    while True:
        for pixel in range(8):
            set_pixel(pixel, r, g, b)
            next = (pixel+1)%8
            set_pixel(next, 0, 0, 0)
def reversed_spacer(r,g,b,seconds):
    while True:
        for pixel in reversed(range(8)):
            set_pixel(pixel, r, g, b)
            prev = (pixel-1)%8
            set_pixel(prev, 0, 0, 0)

def cylon(r,g,b,seconds):
    while True:
        for pixel in reversed(range(8)):
            set_pixel(pixel, r, g, b)
            prev = (pixel-1)%8
            if prev < pixel:
                set_pixel(prev, 0, 0, 0)
        for pixel in range(8):
            set_pixel(pixel, r, g, b)
            next = (pixel+1)%8
            if next > pixel:
                set_pixel(next, 0, 0, 0)

def pulsed_bar(r,g,b,seconds):
    while True:
        for fade in reversed(range(steps)):
            # print (fade)
            for pixel in range(8):
                set_pixel(pixel, r2, g2, b2)

        for fade in range(int(steps/1)):
            for pixel in range(8):
                set_pixel(pixel, r2, g2, b2)


def ipfs(r,g,b,seconds):
    steps=4  # how many stages in gradient
    brightness=0.5 # how bright the lights will get
    bluebright=100 # the brightness of the blue light in the middle (0-255), albeit overriden by input
    dim=1 # increase to dim down the lights
    run = 0 # running count for periodic file access
    while True: # run always (until interruption)
    # first, open from files the required values, which change over time
      if (int(run) % 50 == 1):
        with open(r'~/RateIn', 'r') as f:   # open from file the IN value
            # print(r)
            lines = f.read().splitlines()
            r=int(lines[-1]) # read the value
    # r=int(map(int, f.readline().split())) # prototype, for multiples (stale)

        with open(r'~/RateOut', 'r') as f: # open from file OUT value
            # print(g) # show values, debugging
            lines = f.read().splitlines()

        with open(r'~/Swarm', 'r') as f: # open from file Swarm value
            # print(g) # show values, debugging
            lines = f.read().splitlines()
            # print(bluebright) 

      for fade in reversed(range(steps)):  # fade in effect
#            print(g2) # show values again, debugging
#            print(r2)

            # print(g2) # show values again, debugging
            # print(r2)

            # print (fade)
            for pixel in range(3):  # first 3 LED lights
                set_pixel(pixel, r2/20, (g2*brightness)+(pixel*1), b2/20)

            for pixel in range(5,8): # the other/last 3 lights
                set_pixel(pixel, (r2*brightness)+(pixel*1), g2/20, b2/20)
            if  (bluebright==0):
                set_pixel(3, 255, 255, 255)
                set_pixel(4, 255, 255, 255)
                set_pixel(3, 0, 0, 0)
                set_pixel(4, 0, 0, bluebright)

      for fade in range(int(steps/1)): # fade out effect
            for pixel in range(3):    
                set_pixel(pixel, r2/20, (g2*brightness)+(pixel*1), b2/20)

            for pixel in range(5,8):  
                set_pixel(pixel, (r2*brightness)+(pixel*1), g2/20, b2/20)
            set_pixel(3, 0, 0, bluebright)
            set_pixel(4, 0, 0, 0)

def flashed_bar(r,g,b,seconds):
    while True:
        for half in range(4):
        for half in range(4,8):
        for half in range(4,8):
        for half in range(4):

def handler(signum, frame):
    print("\nSignal handler called with signal", signum)
signal.signal(signal.SIGTERM, handler)
signal.signal(signal.SIGINT,  handler)

# read run-time options

parser = argparse.ArgumentParser(description="Drive 'blinkt' 8-pixel display.")
parser.add_argument("pattern", help="name of light pattern: \
random[1-3], spacer, reversed_spacer, cylon, pulsed_bar, flashed_bar")
parser.add_argument("r", metavar="r", type=int, help="red channel, 0-255")
parser.add_argument("g", metavar="g", type=int, help="green channel, 0-255")
parser.add_argument("b", metavar="b", type=int, help="blue channel, 0-255")
parser.add_argument("timing", metavar="s", type=float, \
                    help="rate of binking in seconds")
options = parser.parse_args()

pattern = options.pattern.lower()
r = options.r
g = options.g
b = options.b
s = options.timing

if pattern == "solid":
elif pattern == "random3":
elif pattern == "random2":
elif pattern == "random1" or pattern == "random":
elif pattern == "spacer":
elif pattern == "reversed_spacer":
elif pattern == "cylon":
elif pattern == "pulsed_bar":
elif pattern == "ipfs":
elif pattern == "flashed_bar":
    print("Unknown pattern")


Example runtime: run-blinkt-ipfs.py ipfs 0 0 0 0.00

Based on or derived from baseline blinkt scripts; requires the hardware and accompanying libraries being installed on the system.

For the code to run properly in the above form, given that it takes input from files, the IPFS values need to be periodically written to disk/card, e.g. for every minute of the day:

* * * * * ipfs stats bw | grep RateIn | cut -d ‘ ‘ -f 2 | cut -d ‘.’ -f 1 >> ~/RateIn
* * * * * ipfs stats bw | grep RateOut | cut -d ‘ ‘ -f 2 | cut -d ‘.’ -f 1 >> ~/RateOut
* * * * * ipfs swarm peers | wc -l >> ~/Swarm

These lists of numbers can, in turn, also produce status reports to be shown in IRC channels. When our git repository becomes public it’ll be included (AGPLv3).


Richard Stallman Refers to Intel’s Management Engine (ME) — or a Back Door — as ‘Master’, and the Processor Intel Lets Us Use as ‘Slave’

Posted in Deception, Free/Libre Software, Hardware at 4:42 pm by Dr. Roy Schestowitz

Video download link

Summary: “The president and founder of the Free Software Foundation will speak about pressing issues in free software today, and will present the winners of the 2018 Free Software Awards,” says the summary (this was 3 years ago, i.e. before the purge of language, with a prominent role played by Intel)

IN HINDSIGHT, or in sight/light of recent news, more people understand that Dr. Stallman was wrongly maligned, maybe even used as somewhat of a scapegoat/sacrificial lamb to distract from what Bill Gates had done in MIT.

“Racism will go away when we get rid of racist companies like the I’s (IBM and Intel, which actively harmed black people, collectively).”In any event, it’s worth reminding people of the message of Stallman on technical and ethical issues, setting aside all the political stuff that he’s being blasted for.

Listen to the above video and pay attention to what he said about 3 minutes into this talk. It’s a subject that I spoke to him about in the past. It’s about microprocessors coming with back doors (more of them over time; it’s not limited to Intel anymore).

Richard Stallman in 2018What I found curious, personally at least, is the fact he used “master” and “slave” as metaphors. That was 3 years ago.

Nowadays the very same companies he’s criticising in his talk are trying to dilute or narrow down our vocabulary, making it harder to express or explain the relationship between us and those abusive corporations that work for the government (their master), not for customers/users (slaves). Racism will go away when we get rid of racist companies like the I’s (IBM and Intel, which actively harmed black people, collectively). Those companies are big contributors to racial injustice. Banning or “eradicating” — as they put it — a bunch of supposedly ‘offensive’ words will accomplish almost nothing in practice.

Photo source and licence: CC BY-SA 4.0


Nathan Proctor: Right to Repair and the DMCA

Posted in DRM, Hardware at 9:26 pm by Dr. Roy Schestowitz

Video download link

LibrePlanet 2019 video. Original here. Slides here.


System76’s First Keyboard Packs in Plenty of Surprises

Posted in Hardware at 10:56 pm by Guest Editorial Team

System76 keyboard

System76 oops

Summary: Putting the genie back in the bottle is hard, and moreover the corrective post from Joey Sneddon may cause a bit of a ‘Streisand Effect’


How To Deal With Your Raspberry Spy — Part IV: Doing The Task

Posted in BSD, GNU/Linux, Hardware, Kernel at 7:59 pm by Guest Editorial Team

By Gavin L. Rebeiro




1 Acknowledgements

2 Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 YOU ARE HERE ☞ Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: We now spell out the steps taken to actually replace the Raspberry Pi OS with something more trustworthy (for background see Part I, Part II, and Part III)

We’ve now covered enough ground to make the installation of
NetBSD on our Raspberry Spy (over our UTUB) a relatively painless matter.

Let’s go through the process in little steps.

4.1 Preparing The Boot Media

I’m going to grab the appropriate NetBSD image by taking hints from the following:

NetBSD/evbarm on Raspberry Pi tells us everything we need to know to pick the right image. All the sections here related to booting are worth reading at least once. Also read sections about consoles and serial consoles at least once.

Raspberry Pi boot modes is useful if you want to dig deeper into the booting mechanisms of the Raspberry Spy. USB mass storage boot is particularly useful for booting off USB. Trust me, you don’t want to muck around with SD cards; they’re a nightmare.

NetBSD/evbarm can be referenced for general information about NetBSD on ARM boards.

The above links should give you a good idea of what’s going on and what needs to be done with regards to putting a NetBSD on a boot media that goes into a Raspberry Spy.

Let’s go through a concrete example.

My Raspberry Spy is of the model “3 B+” variety so I’m dealing with an ARM64 CPU architecture. We’ll follow along the instructions outlined in Installation procedure for NetBSD/evbarm; pay close attention to the section “NetBSD/evbarm subdirectory structure”; I follow these instructions as I explore Index of pub/NetBSD/NetBSD-9.1/evbarm-aarch64/.

I grab the appropriate image like so:

$ mkdir ~/Downloads/netbsd
$ cd ~/Downloads/minted
$ wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/evb c
 → arm-aarch64/binary/gzimg/arm64.img.gz

Now that we’ve got the image, we can write it to our boot media. I’m going to assume you have an appropriate reader already plugged into your GNU/Linux box. I’ve got my USB thumb drive as “/dev/sdg” on my system. Use the right block device file on your system1. We base our procedure along the lines of “Installation for ARMv7 and AArch64 devices with U-Boot” section from Installation procedure for NetBSD/evbarm:

$ gzip --decompress --keep arm64.img.gz
# dd if=arm64.img of=/dev/sdg bs=1M conv=sync
 → status=progress
$ lsblk -f | grep sdg

We’re going to ignore the minutiae of writing to block devices, bootloaders, and other adjacent topics related to the utilities we just used; that’s left for another time. We care about learning how to use a serial console in this project so we must stay focused on our primary target.

We’re going to have a look at how to make a serial install possible via some editing of the “cmdline.txt” file that now resides in the boot media (on the boot partition which is of type “vfat”):

# mkdir /media/netbsd_image
# mount /dev/sdg1 /media/netbsd_image
# grep "console" < cmdline.txt
# root=ld0a console=fb
# grep "enable_uart" < config.txt
# enable_uart=1

The “console=fb” part is to get out OS image to use the HDMI output. We will get rid of that string from the file “cmdline.txt”. Who needs that anyway? One way to do it2:

# ed cmdline.txt
root=ld0a console=fb
root=ld0a console=fb
# echo ",p" | ed cmdline.txt

Remember to check your edits!

We also ensure that “enable_uart=1” is set in the file “config.txt”:

# echo ",p" | ed config.txt

Everything looks good! Additional useful information on the Raspberry Spy UART can be found in UART configuration. Pretty self-explanatory. That wasn’t so hard. Was it? Note that the following links document the files we’ve been messing around with:

The Kernel Command Line

It’s a good idea to back up the state of your image, at this point3. We can now safely unmount our boot media and get on with the project:

# cd ~
# umount /media/netbsd_image

We change directory, before we unmount, so that we don’t get any “device busy” errors.

We’ve now got our boot media ready. Onwards!

4.2 Connecting Physical Components

Before you power up your UTUB, you should really check that the pins are working properly. The very basic test you should do is to check that the right voltage is being supplied. Check out Appendix C.

The pins on our UTUB and Raspberry Spy that we’re interested are the following:

• Raspberry Spy: Pin6 (Ground), Pin8 (GPIO14, TXD), Pin10 (GPIO15, RXD). You can find the layout in the official GPIO page.

• UTUB: I’ve got a CP2104 UTUB so I’ve got to only worry about the pins marked TX, RX, and GND. I have other pins on the module but they’re not relevant for this task.

We won’t be using any of the voltage pins on the boards because it’s more prone to errors. Just use the USB power supply that comes with your Raspberry Spy.

Don’t plug anything into power for the following sequence. Connect the jump-wires like so:

• Ground on UTUB to Ground (Pin6) on Raspberry Spy.

• TX on UTUB to RX (Pin10) on Raspbery Spy.

• RX on UTUB to TX on (Pin8) Raspberry Spy.

“We won’t be using any of the voltage pins on the boards because it’s more prone to errors.”Don’t make the rookie mistake of matching TX with TX and RX with RX; TX always goes to RX and RX always goes to TX. Keep this in mind, always, when working with UARTs. Colour-coding your jump-wires helps.

We’ll just go over the order of attaching the stuff to do with power on our devices:

• Attach the USB power adapter to the Raspberry Pi without plugging the adapter into the power outlet.

• Attach the UTUB to your GNU/Linux box.

• Attach your USB power adapter to your power outlet.

The logic for the above procedure is that you can ensure that your serial interface is up and running before you start getting input from your Raspberry Spy.

4.3 Using Picocom

Using picocom(1) is simple. All we need to do is select the correct baud rate and give the right device file as a parameter to picocom(1).

I’ll give you an extract from the manual page to enlighten you:

In effect, picocom is not an "emulator" per-se. It is a
simple program that opens, configures, manages a serial
port (tty device) and its settings, and connects to it
the terminal emulator you are, most likely, already
→ using
(the terminal window application, xterm, rxvt, system
console, etc).
When picocom starts it opens the tty (serial port)
given as its non-option argument. Unless the
--noinit option is given, it configures the port to
the settings specified by the option-arguments (or
to some default settings), and sets it to "raw"
mode. If --noinit is given, the initialization and
configuration is skipped; the port is just opened.
Following this, if standard input is a tty, picocom
sets the tty to raw mode. Then it goes in a loop
where it listens for input from stdin, or from the
serial port. Input from the serial port is copied
to the standard output while input from the standard
input is copied to the serial port. Picocom also
scans its input stream for a user-specified control
character, called the escape character (being by
default C-a). If the escape character is seen, then
instead of sending it to the serial-device, the
program enters "command mode" and waits for the next
character (which is called the "function
character"). Depending on the value of the function
character, picocom performs one of the operations
described in the COMMANDS section below.

We use “C-a C-x” (Ctrl+a followed by Ctrl+x)4 to tell picocom(1) to exit; for more, RTFM; in particular, pay close attention to the “COMMANDS” section.

Make sure you’ve set up all the physical connections, as advised. It’s time to attach our UTUB to our GNU/Linux box and then make sure we invoke picocom(1) correctly:

# picocom --baud 115200 /dev/ttyUSB0
picocom v3.1

port is         : /dev/ttyUSB0
flowcontrol     : none
baudrate is     : 115200
parity is       : none
databits are    : 8
stopbits are    : 1
escape is       : C-a
local echo is   : no
noinit is       : no
noreset is      : no
hangup is       : no
nolock is       : no
send_cmd is     : sz -vv
receive_cmd is  : rz -vv -E
imap is         : 
omap is         :
emap is         : crcrlf,delbs
logfile is      : none
initstring      : none
exit_after is   : not set
exit is         : no

Type [C-a] [C-h] to see available commands
Terminal ready

It really is that simple. You’ve now got a serial terminal ready and listening.

4.4 OS Installation

Now that you’ve got a serial terminal operational, all we have to do to install NetBSD on the Raspberry Spy is to plug the USB power adapter into the power outlet. Keep a close eye on what goes on in the output of your serial terminal:

[   7.4246937] root device:
[  11.6252523] use one of: mue0 sd0[a-p] ddb halt reboot
[  11.6252523] root device: sd0
[  13.9755661] dump device (default sd0b):
[  15.7257992] file system (default generic):

You should be promoted to pick a root device. I pick “sd0” as it’s the first ’disk’ offered by NetBSD (which can only be my boot media)5. I go for the suggested defaults, for everything else. No need to overcomplicate things, at this point.

You will probably see your Raspberry Spy reboot once or twice during the OS install process. Just pass the same parameters for the boot device, and you should be good to go.

Eventually, you should be met with the following:

NetBSD/evbarm (arm64) (constty)


If you login as “root”, you should have a nice login shell presented to you.

And we are done! You’ve successfully done some tinkering over a serial terminal. That wasn’t so hard. Was it? You can shutdown your device (halt the OS) like so:

# shutdown -p now
[   910.5814809] The operating system has halted.
[   910.5814809] Please press any key to reboot.

You can now disconnect the power supply from your Raspberry Spy. Then just send “C-a C-x” to picocom(1); after which, you should see:

Thanks for using picocom

Welcome to the world of serial terminals; hack your heart out!
1 The command lsblk -f should help you out here. Don’t wipe the wrong device by accident.
2 If you use another text editor, that’s fine. You really should learn ed(1) at some point though, especially if you want to get into embedded systems.
3 At least keep track of the files that you tweaked. If you use some sort of version-control-system, you get bonus points.
4 I don’t know why the manual doesn’t bother to explicitly mention that these are GNU-Emacs-style key sequences.
5 See the NetBSD sd(4) manpage for details.


How To Deal With Your Raspberry Spy — Part II: Introduction

Posted in Free/Libre Software, GNU/Linux, Hardware at 9:01 pm by Guest Editorial Team

By Gavin L. Rebeiro




1 Acknowledgements

2 YOU ARE HERE ☞ Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: Following Part I, published a few hours ago, let’s examine what happened from a technical perspective and what can be done about it technically

We don’t want to be spied on; what happens when we’re faced with an operating system that spies on people? We throw it in the trash where it belongs! I am boycotting the Raspberry Spy myself (you’re free to join me in doing so) but I don’t want people to waste hardware that they already have. So we’re going to walk through an interesting path of installing a different operating system on the Raspberry Spy; I want to show you a few things that will empower you to take greater control over your computing.

We’ll gently walk through and explore the following: how to install an operating system on an embedded device (a Raspberry Spy, in this case) over a USB-to-UART bridge (UTUB). This is the main project we’ve got on our hands. Don’t worry if you’ve never touched embedded systems before; everything here is accessible to people with a modest set of prerequisite knowledge and some basic apparatus.

We’ll delve into things with more depth as we move forward with our project; if you don’t understand something when you first encounter it, just keep reading.

2.1 Prerequisite Knowledge

There’s not much prerequisite knowledge required. Here’s what you need to know:

• A basic grasp of how to operate a shell on a GNU/Linux system. GNU Bash is an example. You don’t need to know how to write shell scripts. Knowledge of how to use the shell interactively will suffice.

That’s it. Really. Anything else you need you will pick up on the way.

2.2 Apparatus

You will need the following apparatus:

• A Raspberry Spy. I’ve got the Raspberry Spy Model 3 B+ so that’s what I’ll be using in this project.

• A working Internet connection.

• A USB thumb drive (used as boot media) for the Raspberry Spy.1

• A power supply for the Raspberry Spy.

• A USB-to-UART bridge (UTUB). I’ve got a CP2104 from Silicon Labs; this is widely available and you can pick it up from an online retailer. You want a module that has all the necessary pins and peripherals already packaged into one, neat, unit. I believe the specific module I have is by WINGONEER.

• 3 female-to-female jump wires.

• A computer with any recent GNU/Linux installed on it. The computer needs to have a working USB port.

• A generic microSD card reader/writer. I have an Anker AR200.

It’s likely that you already have the apparatus to operate your Raspberry Spy. Just acquire the additional bits that you don’t already have. The list here is just for completeness.

Here’s some extra equipment that will make your life easier:

• When you’re dealing with electronics, you should heed the old idiom of “two is one and one is none”. Get spares of whatever you can, as a rule.

• A digital multimeter (DMM) with spare fuses for the multimeter. Being able to do some quality control (QC) before you hook up your UTUB to your hardware is going to give you peace of mind. Don’t skimp on the spare fuses for the DMM; it’s easy to forget how much current you’ve got flowing through a circuit and fry the DMM’s fuse by accident2.

• A 2M or longer USB extension cable. Male-to-female is what you want here. You plug in the male part to your computer and the female part is open for receiving the UTUB. This makes life a lot easier (and safer).

• Nitrile gloves. Helps keep you safe.

• Safety goggles. Again, doesn’t hurt to be careful.

You should now have everything you need to get started!
1 If you’ve got a Raspberry Spy that can only accept an SD card as boot media, you don’t need to fret too much. The procedure is the same; you just write the OS image to an SD card instead of a USB thumb drive. Fixing quirks of SD card installations are, however, out of scope of this project; you should refer to the relevant documentation, IRC chats, and mailing lists. I will provide links to boot-media-specific information, when we discuss boot media; this should give you a starting point to troubleshoot issues.
2 Real fuses were harmed during the making of this document.

« Previous entries Next Page » Next Page »

RSS 64x64RSS Feed: subscribe to the RSS feed for regular updates

Home iconSite Wiki: You can improve this site by helping the extension of the site's content

Home iconSite Home: Background about the site and some key features in the front page

Chat iconIRC Channels: Come and chat with us in real time

New to This Site? Here Are Some Introductory Resources




Samba logo

We support

End software patents


GNU project


EFF bloggers

Comcast is Blocktastic? SavetheInternet.com

Recent Posts