Raspberry Pi® Logo
Valid HTML 4.01 Transitional

Raspberry Pi 3B

Jim Carter, 2018-02-06

Table of Contents

Web Resources

Websites for OpenSuSE installation:

Physically Assembling the Raspberry Pi

In the box (by CanaKit):

The instructions say to defer installing the heat radiators and the SD card until after the case has been assembled around the motherboard. Yes, the SD card probably sticks out too much, but jimc got his first Raspberry Pi before that instruction was added, and didn't have a problem working around the heat radiators while assembling the case.

Getting the motherboard into the case can be a bit of a challenge; be patient. The case has three parts: top, middle and bottom. For orientation, let's call the end with the USB ports the head and the other end, with the card slot underneath, the tail. The side with the power, HDMI and audio ports is the right side. The GPIO header (inside) is on the left side. The leaves in the Raspberry Pi logo end up toward the head end. When you pick up the motherboard, the USB socket and RJ45 make a convenient handle. Avoid touching in random places, to avoid electrostatic discharge, which can damage components.

A Week of Struggling with Power via USB

The actual sequence that I followed was to try, unsuccessfully, to boot the SuSE installer. Then I installed the XFCE image, which booted but which was not able to communicate on Ethernet, and frequently but not always lost its connection to the keyboard, and sometimes lost video. Working through symptoms, I eventually traced the problem to excessive power being drawn from USB by the KVM switch I was using. I bought a powered USB hub, but it was deficient in intelligence, switching between hub and host power, which was fatal. I bought a different hub, and it had its own idiosyncracies, but I was able to get a combination that worked; your mileage will probably vary a lot. Update: I junked the hub and it worked; see the end of this section.

Powered hubs have two variants: with and without a diode in the uplink power line, so the host could send power to the hub for unpowered operation, but power cannot flow from the hub to the host. In the likely case that your hub lacks this diode, the two power supplies would end up connected in parallel, and one of them (the one with the lower output voltage) will provide no power, overloading the other, with bad consequences. Disconnect the Raspberry Pi's power supply and use only the (presumably bigger) hub supply.

There is another fly in the ointment, which I did not progress far enough to encounter: EMI (electromagnetic interference). One reviewer of a different brand of powered USB-3.0 hub said he had a lot of interference with his Bluetooth mouse and Wi-Fi in the 2.4GHz ISM band (his 5GHz Wi-Fi was not affected). Apparently a lot of USB-3.0 devices, including the hub being reviewed, emit electromagnetic interference in this frequency range which particularly affect the computer they are plugged into. Moral: only get a USB-3.0 hub if you are connecting USB-3.0 devices and if 2.4GHz EMI isn't relevant to your use case.

My conclusions from this debacle are:

Update: I retried the KVM switch before condemning it to a life of gathering dust in the basement. And it works! The key step was to get rid of the powered and unpowered hubs; the client USB cables (and video) connect directly to the client machines. The combination of Raspberry Pi and KVM switch draws 6 watts, which the Pi's power supply is able to deliver, including during booting. Moral: on a Raspberry Pi (and similar machines where the USB ports' power and the power supply are suspected of being connected in parallel), use only one power supply. If you have a power hog, get a seven port hub with a big power supply (even if you have only one or two clients), and let the RPi take power from it via the uplink. Assuming it lacks a diode to prevent this kind of power backflow.

A tidbit of information: When the RPi is connected to the keyboard via the KVM switch, occasionally the keyboard works on Grub's user interface, e.g. you can use up-down arrow keys to pick the boot command line variant, but most of the time the keyboard is inert until the operating system gets going. On the other hand, when the physical keyboard is plugged directly into the RPi it is reliably active during booting.

I'm feeling (without proof) this scenario: when each of the boot ROM, bootcode.bin, start.elf and U-Boot want to enumerate USB devices, it first does a USB bus reset, which disables power for all ports. Then, starting at the root port, it enables the port (with power) and waits a limited time for a ready signal. Then it sends Get Device Descriptor, and checks for whatever kind of device it's looking for. If it got a hub, it does this recursively. This procedure is documented for the boot ROM. The timeout is 2 secs (can be tweaked, for the boot ROM and start.elf). But when U-Boot looks for a keyboard, the timeout is probably short, and the KVM switch takes its time getting booted up. So the keyboard is not recognized.

I tried these interventions with no effect on the KVM keyboard: Turn on USB booting for the boot ROM, with a 2 sec timeout. Add a 2 sec delay in start.elf ( boot_delay=x (in secs) in config.txt or (for SuSE) extraconfig.txt).

Installing an Image

So far, I have never been able to put the OpenSuSE installation DVD on a USB stick and boot it. Even with USB booting enabled, I'm pretty sure that the ISO-9660 filesystem completely confuses the boot ROM. My next strategy will be, rather than installing OpenSuSE off the DVD, to install an image and then upgrade and reconfigure it. So which image do I want to download? Since I'm eventually going to put XFCE on the machine, I'm going to use the XFCE image.

This description of installing an image is actually a composite of quite a number of installation attempts. Do these steps on your laptop or desktop computer:

Early Setup Steps

Booting and reviewing boot messages in detail.

This is actually from a subsequent run of kernel 4.14.6 after upgrading to current packages and successful post_jump.

Immediate steps when it's booted for the first time
Package Installation and Update with post_jump

This image is rather up to date, only 1 kernel minor version behind the latest in Tumbleweed for ARM (4.17.13 vs. 4.17.14 on the other RPi, and 4.18.6 on x86_64). I did these steps to install my desired software packages on Orion.

Checking Out Services

Orion passes checkout.sh, my suite of operational tests of many runtime daemons. So the installation procedure is successful — with a few issues that haven't yet been dealt with.

Next Steps to Deployment

The next set of features to be set up are:


I need to turn on onboard sound, and to evaluate whether I am going to use it for audio playback, or a USB sound module. The proceure to activate sound is documented: dtparam=audio=on in /boot/efi/extraconfig.txt , and the onboard sound does basically work, but it needs a more careful evaluation.

Also the HDMI audio channel has to be checked: it shows all the signs of being functional, but I need to move the RPi to the monitor (TV) that has HDMI audio.

Graphics on the GPU.

The Raspberry Pi, as delivered, has no 3D acceleration and renders licensed formats, such as MPEG-2, in software, not on the GPU. I need to buy the extra-cost graphics license, and to run graphics benchmarks with and without it.


The XMPP image has been seen to connect to the access point and receive a DHCP address. I want to get this working, because the upstairs audio playback node (which I very much want to modernize with a RPi) has a pathetic MOCA connection: it works for audio, but maintenance tasks are annoyingly slow because of the combination of a slow CPU and slow networking.


The video playback node needs a Bluetooth keyboard and mouse, for maintenance.

Application Software

For audio playback I have my own software based on GStreamer. All the relevant components seem to be installed and just have to be checked. [Update: it's working fine.]

For video capture and playback I plan to install Kodi, assuming that video playback is satisfactory.

I plan to have a third RPi as my office desktop machine. My needs for CPU power are modest and the RPi is not wimpy so I expect this will go well. Also I use a compute server across the net when significant CPU power is needed.

Sound Setup

Sound cards

The sound drivers have reasonable default names for the cards, so you don't need to provide a udev rule to fix the names. Look in /proc/asound/cards to find them. Avoid using card numbers because they change randomly depending on the order of loading drivers. They are ALSA for onboard sound, and vc4hdmi for HDMI on the graphics connector. Look in /dev/snd/ or /proc/asound/devices to find the sub-device numbers; normally it's 0; often it's 3 for HDMI; but on this device it's also 0. You can do aplay -D hw:ALSA,0 $sound.wav. On a SuSE system they provide /usr/share/sounds/alsa/test.wav .

Onboard Sound (ALSA).

Use alsamixer (suggestion: in a separate window) to set the volume and to un-mute the card. Hit F6 and choose the sound card, then up/down arrow or PgUp/Dn to change the volume. 'm' toggles muting; in the display 00 means it can play, while MM means it is mute. Hit Esc (escape) to escape from the mixer. Use speaker-test -D hw:ALSA,0 -c2 -t wav and it will play voice clips saying Front Left and Front Right until you give it Ctrl-C. Volume 40 (percent) is reasonable for this test, and yes, the output volume does respond to the mixer.

Turtle Beach USB module

This device has USB ID 0d8c:0103, conveniently named TurtleBeach. (But in alsamixer the card name comes out as Audio Advantage MicroII.) It produces sound, but has two bad issues: First, it sets off repeated USB bus resets, which kicks the Ethernet controller off the bus, and network communication is impossible until the sound module is removed. This issue is fatal. Also, the playback volume does not obey the mixer. I have a similar module on another x86_64 machine, and after a recent kernel update (not sure which one, possibly 4.16.1 and continuing at least to 4.17.3), it also ignored volume from the mixer, so I'm calling it a driver bug. Overall, this USB sound module is not going to fly on the RPi.


I connected the RPi to the TV, which has HDMI audio. It works, but with a feature. The vc4hdmi device is for S/PDIF over HDMI, which I haven't tested yet. The ALSA device, which formerly transmitted on the onboard audio, now uses HDMI; I'm assuming without proof that the GPU converts incoming audio samples to S/PDIF. Sound quality is good. So now I have to figure out how to bypass this helpful feature, to get sound on the external speakers (via an amp).

Raspberry Pi doc page for sound gives several methods to configure the sound; the incantation I chose was: amixer cset numid=3 1 where the last argument 1 means analog, 2 means HDMI, and 0 (the default) means use HDMI if the monitor appears to have speakers. On SuSE, amixer is from the alsa-utils package. Once this is set, save the current control values in /var/lib/alsa/asound.state, from which the sound settings will be restored on boot. One way to make this happen is systemctl restart alsa-restore (using the service name from OpenSuSE), in the likely case that alsa-restore is configured to run at boot time. Actually you could just wait until the next reboot and let the settings be stored when alsa-restore is stopped naturally.

ALSA .asoundrc

The playback software (called Grivet) uses the default ALSA sink (output channel), which it determines from $HOME/.asoundrc (where HOME=/home/httpd/htdocs/grivet). The appropriate stanzas for using onboard sound are:

# Raspberry Pi onboard audio
pcm.rpi = {
	type	= hw;
	card	= ALSA;
	device	= 0;
ctl.rpi = {
	type	= hw;
	card	= ALSA;

# Without the '!' there was an error:
# ALSA lib conf.c:1016:(parse_value) pcm is not a string
# My guess is that there is a subsequent overriding value causing this.
pcm.!default	= pcm.rpi;
Sound Quality

With this configuration, Grivet plays the given MRLs, and quality is good. There were no inter-track pops or clicks at all, playing a sequence of tracks out of a M3U file, nor were there hisses or other extraneous noise during the performance. (A forum post mentioned these problems; probably it was for an older RPi model.) Sound quality appears excellent, limited by the headphones and not by the PCM.

FM Radio:

I have a ADS Technologies, Inc. FM Radio Receiver/Instant FM Music (RDX-155-EF), USB ID 06e1:a155. It provides 16bit signed little-endian joint stereo at 48kHz. (Some software reports 96kHz because there are two samples every 2.08e-5 sec.) It actually has 10bit resolution; in other words the bottom byte has values of 0, 64, 128, or 192, and so is easily recognizable. The player software Grivet that worked on the x86_64 playback node also worked on the RPi with one very annoying detail: occasionally bytes are dropped from the USB stream with a probability of something like 1e-3 to 5e-3 (I didn't do actual statistics), with the result that the bottom byte is flipped to become the top byte, and the next channel's top byte becomes the bottom byte. This of course sounds like nonrandom noise.

I compared plugging the receiver into a hub, vs. directly into the RPi; results were unchanged. No Ethernet packets were lost, unlike the case with the Turtle Beach sound module. [Famous last words; on a re-test, it locked up the USB bus.] Various software interventions produced information plus the smoking gun described above, but no cure. So I used a scorched earth policy: I moved the receiver to my gateway, an Intel box, which is running 24/7 and which already has the software from a previous incarnation of the sound playback system.

Bluetooth Setup

Bluetooth setup has been a lot of trouble. The goal of this setup phase is to come up with a working non-wired keyboard and mouse (or touchpad) on my audio-video performance node, Iris. But the setup work is being done first on Orion, which is a lot more accessible. The following line of action succeeded (sort of).

Now comes the part that wasn't successful. This particular folding keyboard is good for extensive writing jobs on a cellphone or tablet, which is what I bought it for, but is not suitable ergonomically for controlling a media node. I have two much more suitable keyboards: a Microsoft Wireless Entertainment Keyboard 7000, and a FAVI FE02RF-BL Wireless Backlit Mini Keyboard with Laser Pointer. (Discontinued in favor of the FE02BT-BL which uses real Bluetooth). Each one comes with a USB dongle, which acts as a USB keyboard and mouse independent of the host's software, so it functions at the earliest stages of booting, e.g. in the Grub shell or GUI, or Intel BIOS setup. I'm not stubborn in my solution; if the proprietary radio link works, I'll use it.

However, when either dongle is plugged into Orion it causes repeated USB bus resets, and in particular the Ethernet NIC (which has a USB interface on RPi) is kicked off the bus, and no Ethernet communication is possible until the dongle is removed. This is a showstopper. The dongles work just fine on Intel hosts. The situation is very reminiscent of what happened with the Turtle Beach sound module.

One alternative fact might be that the dongles use Bluetooth and the keyboards might be able to communicate with a Bluetooth-equipped host. This is true for the Microsoft keyboard, but after about 10 years of service it seems to have given up the ghost; though made discoverable it is invisible to four different Bluetooth peers which are normally reliable. As for the FAVI keyboard, it uses the Holtek/Shenzhen LogoTech 2.4GHz receiver, which is not Bluetooth (and which is used by quite a number of wireless mice and keyboards).

I bought a Jelly Comb B003B Foldable Dual Mode USB Wired & Bluetooth Keyboard and Touchpad ($34.99 on Amazon). The battery recharges on USB, and it also behaves as a wired keyboard if plugged in. It can fold up when not in use. It's operational with the RPi's Bluetooth (wired too). It looks like this keyboard is working out.

I did a survey of most of my USB modules, some of which are really ancient. Order is best to worst, meaning whether it is accepted on the USB bus. I did not evaluate its actual function, e.g. FAX modem, sound module, Wi-Fi NIC, etc.

The conclusion of this survey is that there is something really nasty happening on the USB bus; some devices work fine, while some totally lock up the USB bus and some even provoke daemon and kernel crashes. And in several cases the behavior differed at different times on different RPi's. All of these devices are satisfactory on Intel machines. I doubt that a quick fix will be forthcoming. One of my use cases involves USB mass storage, and I really hope that the rotating disc controller-enclosure will function.

Another persistent issue with Bluetooth is that it sets off a kernel panic when the host reboots or shuts down. The panic seems to vary randomly in location and in the call trace. In the worst case, when it tries to shut down the firmware loader, the host panics. In better cases it stops all the daemons, announces that it is finishing the shutdown, and dies. My impression is that the shutdown code (on ARM) transfers to EFI Runtime Services (on the GPU) to do the actual shutdown or reboot, but this code has been trashed. [Update: with kernel 4.17.14 the pattern has changed.]

I did some tests with Bluetooth on or off. The three services involved were bluetooth-fw.J.service (uses btattach to load the firmware, by jimc), bluetooth-hci.J.service (uses bluetoothctl to give the power on command, by jimc), and bluetooth.service (starts bluetoothd, from the bluez-5.50 package). In testing, either all three were disabled or all three were enabled and started, in the above order, at boot.

A pre-check gave these results:

I rebooted Orion repeatedly with all 3 services disabled. I did almost nothing while the machine was up: just chvt 1 ; systemctl reboot. * indicates a 90 sec timeout for the swap device to become ready; this issue is not related to Bluetooth.

    1 2 3 4 5 (chvt 1 hangs the X-server, won't flip even if X-server stopped)
    6* 7 8 9 10* 11* 12 13 14 15 (chvt 1 hangs again)
    16 17 18 19 20*

20 reboots were performed without a crash. These anomalies were encountered: Twice, chvt 1 locked up (something); whether or not the X-Server was running, it could not complete the transition to VT1 and keyboard and mouse events did not appear on the screen. Four times, during initrd execution there was a start job for /dev/mmcblk0p3 (swap), which continued until it timed out about 90 sec later. Jimc's interpretation: a device unit waits until the device becomes ready, but the man page is not clear what happens if it is already ready, which I suspect is the case. This issue is not related to Bluetooth.

Next, with all 3 services enabled, Orion was rebooted 10 times. Same as before, I did nothing beyond chvt 1 ; systemctl reboot, and in particular, no Bluetooth devices tried to connect. H = panic after stopping bluetooth-hci.J. (At the end of the process.) F = panic after stopping bluetooth-fw.J.

    1 2H 3H 4F 5F 6H 7H 8* 9* 10

It succeeded in rebooting four times, died twice after stopping the btattach process, and died four times after using bluetoothctl to do power off. In a change from previous experience with the 2018-05-11 image (now using 2018-08-13), it consistently got a fatal exception in interrupt. Here's a screenshot:

Graphics Setup

The major issue in graphics setup is to get the GPU (Graphics Processing Unit) to do as much as possible of the work of rendering the image. The term hardware acceleration is often seen but is a misnomer since the GPU is actually a fully programmable compute system with multiple cores each with an ALU (arithmetic and logical unit) optimized for efficient execution of typical graphical primitive computations. The GPU handles the whole boot process until the kernel is ready to run. (On SuSE the kernel is u-boot.)

One major graphics issue is codecs for streaming video. Many contentious issues surround graphic codecs and there are many codecs each with its own strengths and weaknesses; I am certainly at a lower rank in codec expertise. However, here's a simple overview of the codec issues on the Raspberry Pi:

The RPi is intended for students to hack, and therefore a low price is essential. The RPi Foundation decided to not include GPU codec licenses in the price of the whole RPi to make it more accessible to young people; nonetheless, they negotiated this extra cost license scheme with Broadcom for end users whose use cases require multimedia performance.

My main job in this sub-project is to purchase the license, get the firmware loaded, run graphic benchmarks with and without the firmware, and evaluate whether the RPi is going to be suitable for video capture and playback (which several forum posters have reported positively).

However, a key prerequisite is to be able to use the GPU, i.e. to get the free codecs working. This turned out to be a major challenge — actually a documentation issue. The GPU works on other distros (I tried Raspbian and Gentoo-64), but after quite a lot of unsuccessful work including transplanting the Gentoo boot files and kernel, I dug up this forum post on Reddit about Raspberry Pi 3B graphics. OP sdoconnell 3 months ago (2018-07-xx). On 3 RPi's he has OpenSuSE Leap 15 and Kodi, but the frame rate is 3 to 5 fps, which is unwatchable.

sdoconnell solved the problem! He has what he describes as a stuipdly simple solution, which he found in section 1.2.5 of the SLES documentation for Raspberry Pi. Jimc's paraphrase and extension of his solution:

I ran GLMark2 (SuSE package name glmark2), and the overall score was 74. I believe this is the average of the framerates of the individual tests.

Comparison of overall scores:

Conclusion: With the magic incantation, 3D GPU acceleration will work almost out of the box. The GPU speeds up performance by a factor of about 4.4, whereas the laptop is about 100 times faster than a software RPi, and a real game GPU would be faster than that. You won't play modern video games on a RPi, but the GPU acceleration brings important applications within reach, specifically video performance, which has been mentioned favorably in forum posts.

The next step will be to purchase licenses for the video codecs and try them out. Then, install Kodi.

For buying the licenses: Start at the Raspberry Pi Foundation's website. (I had trouble communicating with them via IPv6; temporarily suppressing IPv6 in the browser helped a lot.) Continue to BUY, scroll down to the bottom and find the MPEG-2 and/or VC-1 Licence Keys. The key is a 32bit integer in hex which is a hash (using a non-published algorithm and initialization vector) of the codec ID and the serial number of the specific RPi that's going to use the codec. To find this serial number do dmidecode | grep Serial; only the first core has one. They will deliver the licenses by e-mail; when I did it, delivery was in about 3 hours, but it probably depends on whether you send in your order during working hours in the UK.

To use the license(s), insert in config.txt (/boot/efi/extraconfig.txt for SuSE) decode_MPG2=01234567 (not MPEG2) and/or decode_WVC1=fedcba98. Then reboot.

It's possible to use the vcgencmd command to check which codecs are enabled (and other useful information and settings), but the instance on Raspbian is for a 32bit operating system and libraries, and I was not able to compile it on the 64bit RPi because there is assembly code that appears to be specific for the 32bit architecture. According to this HOWTO for Funtoo Linux (2018-10-16), the codecs that can be queried are H264 MPG2 WVC1 MPG4 MJPG WMV9. To obtain the source code: git clone https://github.com/raspberrypi/userland.git.

An important resource is going to be a collection of video clips, which I plan to perform using VLC. I hit a few sources of video clips:

Here are the URLs to the clips themselves. Plays refers to being played with VLC on the Intel laptop.

Here are the outcomes from playing these files on various machines:

Death Spiral

Oops, got a problem. Consistently, when the XFCE desktop is being used, something locks up after several minutes of use, generally just before I get a video clip started. This symptom is very vague and unrevealing for diagnosis. It is possible (in fact very likely) that the symptoms change when the kernel is upgraded. Here are the facts known before targeted investigation.

What could be causing the symptom?

Some ideas for investigation:

In all of the following failure tests on OpenSuSE, the kernel command line had cma=300M and /proc/meminfo reported CmaTotal: 307200 kB (which is assumed without proof to represent 300*1024*1000 bytes). Swap space of 497972 KiB (total) was available. Bluetooth was off. XFCE's compositor was on by defauilt with window shadows (unless I indicate below that I tried turning it off). In reports of CPU percent used, 100% would mean hogging one of the four cores, or the equivalent in multiple threads.

Two video tests that ought to set off the freezeup: First I run Firefox and scroll as quickly as I can through 1.16Mb of text-only web pages. Then I display 221 photo images (JPEG) each in a simple HTML page, as quick as I can click Next.

Failure test 1: After the above 2 video tests (which did not freeze up), I let it sit for 3.5 hours. The wcreensaver had the display off (DPMS). I hit Shift, The display came on, and the mouse cursor was visible on a black background. It moved following the mouse. No interventions caused content to be displayed. The cursor changed shape appropriately according to what it was over. Having memorized the window placement, I focused on the XTerm and typed echo Test File > /tmp/testfile, and the file appeared (I used a ssh session to see it). Still, only the cursor is visible. I tried killing xscreensaver, didn't help. I killed xfce4-session; the session was killed, the X-Server was restarted, and the greeter session was started… Invisibly. Enough of this; I rebooted. I should have tried flipping VT's; during the reboot when it flipped to VT1, that was visible. [Update: flipping VTs would not have helped; VT1 is visible and VT7 continues to misbehave.]

Failure test 2, trying to provoke the failure promptly.

Failure test 3: With cma=600M.

Failure test 4. This will be on Raspbian (32bit). If it fails the same way, this will prove that the problem is not specific to OpenSuSE, nor to the C compiler. But it is unlikely to fail because a lot of people have been using Raspbian and would have reported a failure like this.

Failure test 5: Repeating the same behavior on OpenSuSE.

To make progress I'm going to need to re-create my Gentoo SD card and run the tests there. See Gentoo64 on Raspberry Pi.

Returning to the Death Spiral

I spent three weeks trying to install Gentoo on the RPi. I eventually got a complete desktop with XFCE and Firefox, but the package that provides vc4_dri.so would not compile and I could not straighten it out; it appears to contain assembly code specific for armv6 (32bit). I did learn a lot from this experience, but the key goal was not met: to prove that the same death spiral occurs on both Gentoo and OpenSuSE. Link to history of Gentoo64 installation.

One thing I've learned with this bug: its manifestation varies according to invisible details, and so it's necessary to repeat tests many times to get a consensus. But in a re-test, the LightDM greeter continues to not hang up if unused, but once I log on and start Firefox, it will behave normally for quite a while but eventually does the death spiral. I've tried several programs including Firefox, and when I exited from them, CmaFree went back to approximately the value before they started. Nonetheless, so far the only program that hangs is Firefox. Update: graphics will freeze up with just an xterm, xload -update 2 (secs), the screensaver (only blanks the screen, DPMS off, no eye candy), and the usual XFCE session infrastructure. But you have to let it incubate: in the test where I was recording timestamps it took 5 hours to freeze. Thus, although Firefox seems to make it fail faster, Firefox (or another graphics-intensive program such as Chromium) is not required to freeze it up. So there is no lonman ger ay reason for me to evaluate other web browsers.

Picking a Web Browser

I started a project to try as many graphical programs as possible. Hung means that CMA free memory decreased in a death spiral. Leaked means that CMA free memory did or didn't return to approximately the start value when the program exited.

Name Hung? Leaked? Libraries Description
xterm No No libX… Terminal emulator
evince No No libgtk-3 PDF viewer (1 crash, 1 success)
ristretto No No libgtk-x11-2.0 Image viewer (OK)
AisleRiot No No libgtk-3 Solitaire game (OK)
gbrainy No No In Mono Brain teasers (OK)
Mahjongg No No libgtk-3 Tile matcher (missing tiles)
gnumeric No No libgtk-3 Spreadsheet (OK)

Since a quick fix is unlikely for the death spiral issue, and since Firefox is apparently doing something that sets it off, more so than other programs, if I want to use the Raspberry Pi in a desktop role, I'm going to have to use other than Firefox. So which web browser shall I pick? Of course the choices will have to be tested long-term to see if they also set off the death spiral.

The main competitor to Firefox is Google's Chrome, apparently now surpassing it greatly in market share. This program has extensive integration with Google's information ecosystem, both bringing Google services such as Gmail and Google Documents to the user, and bringing to Google unknown but probably extensive intelligence about what the user is doing, that can be monetized. The foundation is called Chromium and is open source (0.13% market share), and Google's helpful user experience augmentations (including the H.264 codec) are believed to be separate. I used Chromium for a while several years ago and decided that I liked Firefox better. I am inclined to put Chromium at the end of the line, for consideration as the replacement web browser. So I'm going to consider lesser browsers and am going to have to decide which features and aspects I am willing to give up.

Market share of major web browsers, 2017-05-xx (graphed back to 2009), from StatCounter, presented on Wikipedia. Major means over 2% at any time in this interval. The metric is page loads including linked items such as style sheets and advertising, summed over all webservers.

Usage Share of Web Browsers on Wikipedia. This page has lots and lots of tables showing market share in different ways, and a discussion of biases and inaccuracies in collecting these statistics. I'm showing here the distribution of page loads (vs. unique visitors) summed over all Wikimedia sites (i.e. Wikipedia and friends). Wikimedia pages tend to not have voluminous showers of linked files, nor do they have any advertising, so this data is likely to be more comprehensible and reliable than others. The table is dated 2018-10-xx (it's the first one on the page).

A quick look at non-major browsers does not reveal promising candidates. The problem with a non-major browser is that as usage dwindles it is likely to become extinct, leaving me with the need to do this selection again.

UC Browser is completely unknown to me, and I'll be interested to find out what it is. A map showing the majority browser by country has UC in the lead in India and Mali. (And Firefox in Germany and a few Caribbean islands, Opera in most of Africa plus Uzbekistan, and Chrome everywhere else.) Wikipedia article about UC. It was first released in 2004 by UCWeb, a subsidiary of the Alibaba Group, a major Chinese e-commerce company. It has a bad reputation for security. I'm dropping this one like a hot potato.

It looks like all major browsers are excluded for the RPi role except for my last choice, Google's Chromium. Now I'm installing and testing it. Yes it is available for aarch64. 191Mb installed.

My conclusion here is that Chromium sets off the death spiral just like Firefox does. The good news is, I don't have to deal with Chromium any more. The bad news is that I don't have any web browser at all. [Update: graphics can freeze up with no web browser and no other major graphics program, and graphics can freeze with no death spiral and in fact no visible effect on CMA memory at all.]

Kernel Hacking

This is a known bug. cma_alloc: alloc failed #2680 (2018-09-12, OP cbxbiker61). I posted a bug report with OpenSuSE (bug 1117095, 2018-11-22) asking for help coming up with a non-freezing kernel.

My goal in this step is to duplicate the mitigation steps in the above bug report, and to come up with a vc4 driver and/or whole kernel that does not freeze up. I will alter /etc/default/grub so my hacked kernel is preferred over more recent distro versions. I will have to keep a close eye on the kernel changelogs, and when a security issue turns up that affects me, I will have to rebuild my custom kernel. The commit reversions listed are just band-aids, and let's hope that the real bug is fixed soon. If I could find the issue that would be great, but I think that will be very unlikely.

OP cbxbiker61 (2018-09-12) runs Kodi on a RPi (doesn't say the model or the distro). Respondent HiassofT runs LibreELEC/Kodi on RPi 3B+. This was kernel 4.14.68. Respondent detule proposes reverting both of these commits (they seem to be identified by the first 32 bits of their hash). HiassofT agrees.

Near the end on 10-06, HiassofT identifies

We have kernel 4.18.15. Plan: to check out the 4.18.y kernel source, up to the latter commit, and build it. Now here's a question: are all these commits affecting core kernel functions, i.e. memory allocation? That seems very plausible. It would be nice to be able to just hack the vc4.ko driver, but I doubt that's going to happen.

The checked-out tree will go on Orion (the RPi) in /scr/deathspiral/ . I'll use giggle, a graphical front end for git. Executing as myself, not root.

Clearly kernel 4.14.84 does not have the fixes described. Trying the same thing with 4.18.y.

Hacking LightDM

It seems like whenever my disto does a major version upgrade, the greeter gets horked. The greeter is the thing on X-Windows where you give your loginID and password, pick a session type, etc. It is a major component of the display manager, which typically on desktop Linux starts the appropriate X-Server on the host's physical monitor, then invokes the greeter on that X-Server, obtains the user's loginID and password (or other authentication mechanism), and if authentication succeeds, starts the selected X-Session. Some display managers can also deal with displays on other hosts such as X-Terminals or thin clients.

By now I've tried every common display manager, and several obscure ones. I'm currently using mdm (Mint Display Manager). But it is not available in Tumbleweed for aarch64. Do I want to recompile it from source? It has its idiosyncracies, and the default greeter in the XFCE image is LightDM. What if I revert to LightDM?

Several years ago I used the LightDM Webkit greeter and had a nice theme meeting all my requirements, but at that time some part of it was a bit flaky, and it succumbed to a bug fix in a new version. So I moved on to the next choice, mdm.

My requirements for the greeter are:

Customizing the LightDM GTK Greeter, OP ArcticDog (2012-02-08). As of 2018-06-25 jimc is using lightdm-gtk-greeter-2.0.5 which has several differences in configuration parameters from the version ArcticDog used.

I also tried lightdm-slick-greeter-1.1.4 . But it is strongly oriented to the user list, and I could not get it to show my background; it wanted solid black. So I went back to lightdm-gtk-greeter. Useful lessons learned:

Procedure to install:

Nightmare! On the last and most insignificant host that I was switching over to LightDM, the greeter would not appear. The ancient monitor is driven via a DVI cable that has working VGA lines. After a ridiculous amount of troubleshooting, I found these facts:

A quick and dirty fix was to connect from the physical HDMI port on the host to the DVI port on the monitor, using an adapter, precluding connection of VGA-0. Now the root window has only one segment, and the greeter is on it. Whew!

Bricked Your Raspberry Pi?

A big advantage of the Raspberry Pi over the typical firmware setup in an ARM-based cellphone is, if you mess up the software so badly that it will not boot, you can transfer the SD card to your big machine and do repairs there; if necessary you can just re-image the card. In all of the uproar getting the Raspberry Pi working, I had a few untoward experiences.

At a certain point I bricked my machine. The symptom was, it would go through bootcode.bin, start.elf and u-boot.bin, then start Grub, which exuded the message Failed to boot both default and fallback entries. It then dropped into a Grub shell. The problem was, while trying to straighten out version skew between Orion, Iris and the pristine XFCE image, I got Iris' /boot/efi/EFI/BOOT/grub.cfg onto Orion, and it gives the UUID of the root filesystem, which is on Iris, not Orion. Thus Orion's Grub could not read Iris' root filesystem to find /boot/grub2/grub.cfg (not to mention the kernel and initrd specified in grub.cfg), and things went downhill from there. To discover the correct UUID, insert the SD card in your big computer and do ls -l /dev/disk/by-uuid/, and look for the symbolic link to ../../mmcblk1p2 (assuming you have the usual root filesystem on partition 2). The 1-component filename of that file, e.g. edf0b932-eb7e-4c54-91be-fd7861e59783, is the UUID you need. When I edited Orion's /boot/efi/EFI/BOOT/grub.cfg with the UUID of its own root partition, it once again could boot.

I had a lot of trouble getting the basic boot parameters right, with the result that the X-Windows server would not start, or the RPi would go into a bootloop. How to recognize a bootloop: When you turn on power, the red light comes on, the green light gives a few irregular flashes, then it waits for (I think) 2 seconds, then repeats the same flashes, forever. Just turn off power, transfer the SD card to the big computer, and revert whatever destructive change you just made.

Appendix: Setting Up the Distro Mirror for Tumbleweed

Appendix: Tumbleweed Preparation

My enterprise repo until now has only had x86_64 and i586 (Intel) packages. It's going to take some work to make the installation scripts switch correctly between those and aarch64 (ARM).

Appendix: Package Installation Script Improvements

At present the hacked configuration files are in /home/post_jump/$VERSION (mostly) and /home/post_jump/byhg/$HOSTGROUP, where the latter can include @$VERSION (intersection). There are various scripts that depend implicitly on this directory structure. But architecture-dependent files, like the repo definitions in /etc/zypp/repos.d, are handled poorly, and in particular the x86_64 repos would either not be excluded from the ARM machine(s), or would not be found at all for the x86_64 machines. So I'm going to make everything based on hostgroups.

On CouchNet I have a configuration file that defines sets of hosts, and a program hostgroup that takes an expression such as x86_64@virtual (@ for set intersection) and emits its members on stdout; there's also a Perl API. Numeric version hostgroups are like v42.1, and I'm using v99.8 to represent Tumbleweed.

The new paradigm will go like this: The files that should be the same on machines of all versions and architectures go in /home/post_jump/byhg/all. /home/post_jump/byhg/v99.8 (and other versions) becomes the main version-specific directory. /home/post_jump/current is a symlink that indicates the current default version; formerly it pointed to 99.8 (in the same directory) but this will change to byhg/v99.8 . Sample bash code: opt_R=$(readlink ./current); opt_R=${opt_R##*/v}; This works on both the old and new values for ./current .

These scripts rely on the post_jump directory structure:

Appendix: Setting Up VNC/RDP

Due to issues sharing the monitor, I need to set up remote access, and not just ssh: I need a complete desktop. I've been pleased with RDP on Windows, using Remmina as the client, and I'm going to take this opportunity to evaluate RDP for Linux.

I first tried xrdp. However, the RDP server was not found and I ended up with the Xvnc server (managed by xrdp, and on the ms-wbt-server port, i.e. RDP). There is no indication in documentation or forum postings that it uses other than the RFB (VNC) protocol, though. It performed reasonably, about 5FPS for glmark2.

When I selected the Xorg session, it loaded /usr/lib64/xorg/modules/libxorgxrdp.so which evidently uses the authentic RDP protocol to communicate with the client. It starts off initially with 640x480px and 800x600px, but eventually resizes the screen to the requested 1280x960px. The frame rate was worse, estimated 1FPS for glmark2.

I tried the console session. It asked for a password (no userID), and tried to connect to a VNC server, which was not running.

Trying neutrinordp-any. It wants an IP address, port number (prefilled with 3389 = ms-wbt-server, loginID and password. Error loading libxrdpneutrinordp.so, try lib=libxrdp-vnc.so in xrdp.ini. (I didn't follow this up.)

Now, how do we get a decent graphic benchmark? Here's a short tutorial, How to benchmark your GPU on Linux by Bill Toulas (date not obvious). glxgears is good as a quick test if your graphics is working, but all modern graphics cards get 60 FPS (locked to vertical refresh), so it's useless for comparisons. glmark2 has a rich set of tests for OpenGL ES 2.0. It includes a Wayland tester. Unigine is mainly a proprietary package for professional tests, but they have four free game worlds any of which will provide an extensive and thorough test of game-type performance. I'm going to install glmark2. It's on SuSE Build Service. No dependencies.

For glmark2, the default window size is 800x600px. Full screen, or an arbitrary size, can be set. It also has a run forever mode, for battery testing.

During the test, the RPi draws 5W. It's not clear how much work was being done by the GPU vs. CPU but it's supposed to be using the GPU as much as possible. Final score: 17, compared to 1831 on Xena. It looks like the average FPS over all the 33 tests. Glmark2 is set up to use 10 to 15 secs per test, however many frames can be shown in that time. It took 6 mins on Xena. Via RDP (Xorg server), the average score was 11; it took 7.5min; and the displayed image was limited to about 1 FPS by network delays. Via Xvnc server the average score was 10, but the displayed image had a much higher frame rate, around 5FPS. Several tests did not finish within the alloted time and got a score of 0. This was all with RDP quality set to Best. These must have been all in the CPU without GPU acceleration. Network speed would have limited the perception of quality, but would not have slowed down rendering.

Appendix and Diversion: Raspberry Pi in QEMU Virtual Machine

I need to make progress on this project from a remote location for a week. When I hork my RPi, the procedure is to pull the power plug, remove the SD card, stick it in the card slot of my laptop, fix (ranging up to re-imaging the card), and then reassemble the RPi. These are hands-on operations and I have no robot to do them for me. The obvious solution is to use a virtual machine. I already have a choice of three VM hosts, so it should be a piece of cake. Famous last words.

This project so far has not produced a useful virtual machine. Lessons learned:

Appendix: Serial Cable

All attempts to boot the SuSE installer variants failed, with the video off and catatonic behavior from the USB memory stick. It's going to take the serial cable to straighten this out. (It's really going to take sane power distribution and a FAT32 filesystem to straighten this out.)

Wiki page about serial cable on ELinux .org.

Adafruit's tutorial on the serial port.

Appendix: Improving the Installation Process

In this re-try I want to accomplish several steps:

Appendix: Configuring the GPU

The graphics usually fails with a variety of symptoms. In the most recent incarnation, when display-manager.service starts, it successfully displays the background image for the greeter, then maunders resource temporarily unavailable and dies with a blank screen except for a text cursor. In addition, when the machine is rebooted or halted, when it has finished the whole shutdown procedure (in this incarnation) and announces reached target shutdown, beginning reboot, it gets a kernel oops with different diagnostics on different reboots, none seeming relevant. Quite a lot of interventions (not recorded here in detail) lead to these conclusions:

Next try will be to restore all packages that were removed during the upgrade. Restoration was uneventful. With all those packages added, the RPi failed equally: display-manager died after showing the background, and an oops after stopping all services and starting the reboot.

Removing all packages that were installed during the upgrade (excluding those that were upgraded). Again, deletion was uneventful, and there was no change in behavior: display-manager died after showing the background, and an oops after stopping all services and starting the reboot.

I've set up post_jump so it can stop installation after installing configuration files. Steps to use this:

OK, that strategy was effective in pointing attention at the actual problem.

As for the crash on reboot: there are two suspects, Bluetooth and sound. For quite a while, the RPi could be rebooted without crashing, but just when installation issues were fixed and I went on to investigate the crashes, it started again. On another machine, rebooting soon after taking it down had a bad effect, but in this case, an 8 hour wait did not prevent crashing. I'm going to try one test in each of four conditions:

Given that the Bluetooth and Wi-Fi are integrated, could the Wi-Fi driver be a problem? Its driver is brcmfmac. I blacklisted the driver, and the outcome was worse than before; it could not chvt 1, which it could do consistently before, and hung at an unknown point in the shutdown process.

I suspect there is no precise causal connection between these various interventions by loading or blacklisting different drivers: there is some entirely different issue involving mismapped memory, and the various loaded drivers move different pieces of code into the kill zone.

Appendix: Troubleshooting Graphics in the XFCE Image

I'm convinced that the XFCE image is defective, and I want to track this down. I see these symptom clusters. vchiq is an actual module name; vc4-drm is not a real module but appears in kernel messages. It is probably a hybrid of the real modules drm and drm_kms_helper.

We have these clues:

Action plan:

Appendix: Troubleshooting Graphics in the XFCE Image (Again)

Let's remember: the XFCE image being used here is openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3.aarch64-2018.04.30-Build2.3.raw.xz

The previous attempt did not result in a working installation, but the finger of blame points at the EFI boot files, specifically /boot/efi/EFI/opensuse/grubaa64.efi is present in the version that fails, but completely missing in the pristine image, which appears to use /boot/efi/EFI/BOOT/bootaa64.efi (which is also present in the other image but I'm assuming it's unused). grubaa64.efi appears when you run grub2-install /dev/mmcblk0.

To reimage the SD card I did these steps:

At this point it was in state A, i.e. everything works and you can reboot without crashing.

I executed grub2-install /dev/mmcblk0. This image has a MSDOS (MBR) partition table, hence error messages about a botched GPT, which evidently count as no error reported. Here's the output:

orion:~ # grub2-install /dev/mmcblk0 |& tee $j/grub.log
Installing for arm64-efi platform.
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
GUID Partition Table Header signature is wrong: 0 != 5452415020494645
Could not prepare Boot variable: Invalid argument
Installation finished. No error reported.

Now rebooting: it rebooted without crashing and got the net back up in 70 sec, which is normal behavior. Remember that this is under the influence of grub from the pristine image, e.g. EFI runtime services. /boot/efi/EFI/opensuse/grubaa64.efi is now present.

Now the real test: reboot it again. Unfortunately it reboots with no visible problems. Twice.

I'm going to take this opportunity to try the GPT again. We have a near-pristine image with a MSDOS partition table and a SuSE EFI booter. Now on the laptop I am converting it to a GPT. It did not boot.

Trying the same maneuver on a truly pristine image. It didn't boot either.

The HCL has instructions for creating a hybrid MBR/GPT using program gdisk from the gptfdisk package. After I converted the MBR into a GPT, it reports that I have a protective MBR and a GPT. Commands:

OK, it booted. Then I tried rebooting. It went down OK, but hung with a blank screen. Conclusion: the promised booting from GPT is not really working, and I'm going to have to give this up pending future improvements.

There's a newer image, which I'm trying, dated 2018-05-11. Filename: openSUSE-Tumbleweed-ARM-XFCE-efi.aarch64-2018.05.11-Build1.1.raw.xz This image is fully compliant with SuSE's standards:

I have been dragging my heels with btrfs because I would need to learn a lot about it. SuSE tends to put directories like /var in sub-partitions with an upper bound on size, which is a good idea, but I don't know the details. Anyway, I'm going to try out this new image.

Prerequisite: I need the btrfs utilites, package btrfsprogs, plus the recommended dependency btrfsmaintenance. We get snapper also. And libreiserfscore0 (why?) It's enabled these new services: btrfsmaintenance-refresh.service btrfsmaintenance-refresh.path btrfs-balance.timer btrfs-defrag.timer btrfs-scrub.timer btrfs-trim.timer . I'm going to toss btrfsmaintenance, not having any permanent btrfs filesystems on my laptop. And it rebuilt my initrd's with btrfs support.

btrfs no longer has a fsck module that works. It prints a message, use the check subcommand of the btrfs program. (Tidbit: you can convert a ext2-3-4 filesystem to btrfs in place using the btrfs-convert utility.) See the btrfs-check man page. Command line: btrfs check -p /dev/mmcblk0p3

Installation steps:

Now installing the new XFCE RPi image dated 2018-05-11, filename openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3.aarch64-2018.05.11-Build1.1.raw.xz It boots. (USB keyboard is inert.) Looks normal except that it failed to get a DHCP address (IPv4 or 6). I added those manually. Now running post_jump. Discreps:

Booting the RPI:

Appendix: Lessons Learned While Straightening Out the Display

  • Web resources found:

  • Beware: I have the distinct impression that the boot system has evolved rapidly, and instructions that may have been appropriate a year ago may give poor results today.

  • These are the hardware-specific packages that are required:

  • I discovered a key item: to make the onboard sound work, you need dtparam=audio=on in /boot/efi/extraconfig.txt .

  • Summary of boot modes:

  • Boot process continued…

  • I had a lot of trouble getting the basic boot parameters right, with the result that the X-Windows server would not start, or the RPi would go into a bootloop. How to recognize a bootloop: When you turn on power, the red light comes on, the green light gives a few irregular flashes, then it waits for (I think) 2 seconds, then repeats the same flashes, forever.

  • Here are the config.txt parameters that eventually worked. Actually SuSE provides an official config.txt, and it's recommended to override or supplement things in extraconfig.txt (in the same directory), which config.txt includes. On the SuSE system there is a complete copy of all the setup files in /boot/vc/ but the ones used at boot are in the first FAT partition, which is mounted on /boot/efi . Occasionally forum posts suggest that /boot/vc/config.txt will also be honored, but reading and obeying config.txt is a prerequisite for execing the ARM code that can read UNIX filesystems. I suspect that something copies all of /boot/vc/ including its config.txt into /boot/efi/ and the latter is the only instance that has any effect.

    Also these parameters need to be coordinated with kernel command line arguments, see next section.

  • Matching kernel command line parameters:

  • Seen in log files:

  • With this configuration the RPi boots and the display is normal (though not too swift). But when I try to reboot or shutdown, it gets a kernel oops, not the same every time. Hiss, boo!

    Appendix: Twelfth Installation: Booter Files That Work Together

    I believe I have finally figured out where the culprits are that make the RPi crash on rebooting.

    The first step was to keep the post_jumped root filesystem (partition 2), but replace the boot files (partition 1) with the ones in the pristine XFCE image. This is openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3.aarch64-2018.05.11-Build1.1.raw.xz . Most of the files (FDTs and overlays mostly) are identical; these differ:

    About EFI/BOOT/earlyboot.cfg: Clearly the image version has to have the UUID of the root partition in the image. I'm guessing without proof that when the initrd expands that filesystem to fill vacant space on the card, it gives the partition a new UUID and sticks it in earlyboot.cfg and /etc/fstab.

    With only boot files from the image, it showed a generic grub shell with a command prompt, but showed no sign of having found grub.cfg. Attempted mitigations:

    I tried installing post_jump versions with these results:

    More speculations on the crash on reboot: The watchdog barks but also crashes (differently) on its reboot attempt. Sometimes the crashes seem similar. I believe they are never byte-for-byte identical. They appear to vary when different drivers are loaded (Bluetooth, Wi-Fi). The stack trace looks tantalizingly plausible, i.e. locations in possibly relevant subroutines are listed, but none catch my eye as smoking guns. My strategy has been to not try to copy down exact trace info since it is variable and probably not too informative. My speculation is that dracut-shutdown.service runs successfully, but then somebody calls EFI Runtime Services to get into ACPI to actually reboot or power off the machine, and this call is botched, either because somebody scrambled the jump address, or because Runtime Services was freed out of memory. I have been having similar problems on my Intel x86_64 laptop with OpenSuSE Tumbleweed, kernel 4.17.1 on GPT: on power off or reboot it hangs with no messages when it would be expected to call ACPI. But with the advent of kernel 4.17.2 it hasn't failed yet (at least 10 tries, cross fingers). So the finger of blame might point not in an ARM-specific direction.

    Now that I have a mitigation kludge for the crash on reboot. I once again installed the XFCE image and ran post_jump on it. Discrepancies:

    checkout.sh discrepancies: None significant, and it rebooted without crashing. So this phase has been a success.

    Appendix: Raspberry Pi Boot Process

    Web resources:

    Here's a summary of USB host boot modes, mainly from the last reference above:


    These sectons describe botched steps that were eventually replaced. They are preserved here in case sections may be useful in other contexts.

    Outtake: Preparation: Download Media Discs Etc.

    In the past I downloaded a current ISO image and mounted it on my distro server, so a lot of packages would be obtained from there. With my present distro mirror organization, this is not so useful, plus with Tumbleweed the ISO gets out of date very quickly. So this procedure has been relegated to the outtake section.

    mkdir -p /s1/SuSE/SuSE-build/aarch64/99.8/iso (following my usual distro directory scheme). Download URL: http://download.opensuse.org/ports/aarch64/tumbleweed/iso/openSUSE-Tumbleweed-DVD-aarch64-Current.iso The Tumbleweed ISO is 4Gb in size; on my network at 5Mbyte/sec it took 843sec or 14min. Actual name: openSUSE-Tumbleweed-DVD-aarch64-Snapshot20180203-Media.iso . Unfortunately for us tinfoil hat folks, there are no checksum files. (Actually the package and index files have individual checksums, but an overall checksum would be appreciated.) Copied to an 8Gb USB storage stick.

    Following the HCL instructions: I'm going to host it on my laptop, which has a card slot. The instructions say to install raspberrypi-firmware-config-rpi3 (and its dependency), copy relevant files to the SD card, and then remove the package, but I'm going to leave it installed for future RPi installations. U-boot is for aarch64, not the architecture on my laptop :-), so you need to extract the content with rpm2cpio. I'm going to leave the package file in /s1/SuSE/SuSE-build/aarch64/99.8/suse/aarch64/ . Search for the current version using the SuSE package searcher, under the name u-boot, and once found, expand the list of 151 sub-packages and pick u-boot-rpi3. The Base:System version is 2016.09.01; the most current one (excluding staging) is 2018.01. I'm going to be brave and use the latter one (265kb).

    Since the package was received from mirror.yandex.ru, I wanted to check the package, using rpm -V -p/net/diamond/s1/SuSE/SuSE-build/aarch64/99.8/suse/aarch64/u-boot-rpi3-2018.01-4.2.aarch64.rpm. I obtained the key for the Hardware OBS Project, but was not able to get it into the correct keyring so rpm could find it. See below for a more successful checking procedure.

    Copy the OpenSuSE ISO image of Tumbleweed onto a USB memory stick. Actually I was never able to get things working so this image would become useful. Recommended command line from the SuSE HCL page:
    dd if=[image].iso of=/dev/[usb_key] bs=4M iflag=direct,fullblock oflag=direct

    Outtake: USB Power Distribution

    I'm going to describe the configuration that worked, and then summarize failures at the end. Update: I found a better working configuration, detailed after the failures.

    I have an IOGear 2-Port HDMI Cable KVM Switch with Cables and Audio (GCS62HU). You connect the shared keyboard (USB), video (HDMI) and mouse (USB) to the unit (I didn't mess with audio), and there are two cable bundles that run to the client computers. It is bus powered, that is, it gets its operating power from the clients' USB buses. It has these features and idiosyncracies, some of which make trouble in my use case:

    This kludge is the combination that I eventually made to work. The powered USB hub used here is the Macally 4 Port Powered USB 2.0 Hub with 5V 2A Power Adapter.

    This done, the Raspberry Pi boots, uses the Ethernet NIC (which is on the USB bus), and can communicate reliably with the keyboard and mouse at all stages of booting and operating system use. Including when the NUC is powered up; you can switch focus between the machines with no anomalies noticed.

    These variants were non-working:

    It's hard to understand the power distribution logic in the hubs. I would expect something very simple: when the AC power supply is plugged in, it is used; otherwise the uplink's bus power is used. However, user-level simple is not necessary simple at the electronic level. After thinking about how to do power disribution physically and meet the price goals, I've come up with a total speculation: AC power, uplink bus power, and client power are all connected in parallel, and the hub does not manage power at all. And the Raspberry Pi is known to have a 5 port hub chip in it (Ethernet and 4 USB-2.0 type A external ports); the micro-USB power connector may or may not also be connected in parallel without management.

    This means that whichever power source has the highest voltage will provide all the current. A power supply producing nominally 5V actually produces a fraction of a volt more or less, different for each supply module. If the Raspberry Pi plus the KVM draw more than the rated current of that power supply, you would hope that the supply would let the voltage droop until the other supply starts helping out, or until the load draws within the available current due to series resistance. However, in case of a short circuit or similar damage on the motherboard, this could be hazardous, and some (possibly all) power supplies shut down briefly. The one on the NUC is known to do this, and the BIOS has a setting to head off power supply shutdowns caused by overclocking. The CPU runs at reduced voltage through a DC to DC converter, which has filtering and probably can provide relatively stable power despite weird behavior on the 5 volt side, but a power supply shutdown cannot be good for the USB devices, particularly Ethernet.

    This all sounds plausible, except for one unexplained symptom: why does it matter if two vs. one client cable is plugged into the powered hub?

    Outtake: Hunting for the Missing Drivers

    The previous upgrade got into trouble because of missing drivers for Wi-Fi, Bluetooth, and the X-Server. Now I'm analysing the freshly reinstalled image.

    Outtake: Setting Up the SD Card (Outtake)

    This setup procedure is valid but is for a use case for which I was never able to achieve the prerequisites.

    Following along in the Hardware Compatibility List instructions:

    Outtake: Booting the SuSE Installer

    I never did get the SuSE installer to boot.

    Outtake: Booting the SuSE Installer (Again)

    I never did get the SuSE installer to boot. Here's what I tried:

    Outtake: Bootable Installation Media on USB (Again #3)

    I'm trying again to build a USB stick with the SuSE installer on it. Following along in Create a USB-Bootable aarch64 openSUSE Raspberry Pi-3.

    Major step 1: one-time installation of boot ROM.

    Step 0 is actually to find out what boot ROM version is already installed.

    In this forum post on installing vcgencmd (on Kali Linux, 2015-09-19, OP ivanhertanto, answer by DougieLawson), the recommended procedure was:

    cd /tmp #Or whatever directory
    git clone https://github.com/raspberrypi/userland
    cd userland

    However, the RPi 3B has a 64bit CPU (aarch64) and the soure code contains assembly code that's specific to arm6l (32bit) and has a lot of casts of a 64bit pointer to a 32bit int; it would not compile.

    On a disused 4Gb SD card I put Raspbian Stretch Lite from the Official download site (dated 2018-04-18, kernel 4.14, size 350Mb compressed, 1.9Gb uncompressed). Command line:
    unzip -p raspbian_lite_latest > /dev/mmcblk0
    Warning: make very sure that you are overwriting the correct block device, the full disc vs. individual partitions. Decompression took about 180 secs.

    After unzipping, partition 1 (EFI) has 45Mb, partition 2 (root) has 1.8Gb, and there is no swap. Boot procedure:

    • It takes a while, with the screen blank but the green LED more than usually active. Eventually it pops into a standard-looking systemd boot sequence.
    • To log in, your user ID is pi and the password is raspberry. Change it as the very first thing you do. This is Debian; use sudo for all commands to be done as root.
    • It's on the net but ssh is not running. Do this at the console.
    • sudo parted /dev/mmcblk0: 45Mb EFI, 4.0Gb root. It expanded the root partition to fill the whole card.
    • They gave me a weird keyboard configuration. sudo raspi-config
      • Use the down-arrow key to scroll to 4-Localization Options and hit Enter. (To get out, right arrow to Finish or Back and hit Enter.)
      • Scroll to 1-Change Locale. It thinks you are in the UK, which in my case became false in 1776.
      • Scroll down to en_US.UTF-8 UTF-8 (use Page Down and arrows). Hit Enter.
      • It wants the default locale to be en_GB.UTF-8. I changed to C.UTF-8. Hit Enter. It returns to the main screen.
      • Scroll to 4-Localization, then 3-Change Keyboard Layout, and hit Enter. Wait for it to load its list.
      • I was given Generic 105-key (Intl) PC. Scroll up to Generic 104-key PC and hit Enter.
      • Now it wants the layout: scroll to and pick Other (i.e. not UK).
      • Instead of English (UK), change to English (US).
      • Select plain English (US) unless you want to be able to switch to an alternate layout such as Cherokee.
      • Accept the default for the AltGr key. And the default of no Compose key (use Ctrl-Period instead).
      • Right arrow to Finish.
      • Test the keys that were giving trouble: for me,
        echo "|#^"
        It's fixed.

      Following the procedure in How to boot from a USB Mass Storage Device on a Raspberry Pi 3 for establishing USB boot mode.

      • Make sure you have up-to-date boot files:
        sudo apt-get update
        sudo apt-get upgrade #If update succeeded
      • For Debian, our package architecture is called armhf and uname -m says armv7l. The boot files were not updated (package raspberrypi-firmware-dt on SuSE; not sure on Raspbian).
      • On Raspbian, the green LED indicates either CPU or I/O activity. I believe there is documentation how to turn this on, but it's not on by default on SuSE.
      • Pre-check by printing out the OTP (nonvolatile) config bits:
        vcgencmd otp_dump | grep 17:
        It should say 17:3020000a. Does say 17:1020000a. The 0x20000000 bit needs to be turned on. Warning: There's no way to turn it off again.
      • Append to /boot/config.txt (on SuSE this would be /boot/efi/config.txt): program_usb_boot_mode=1 . For the editor, vi (probably vim) works, or you can use nano, or you can use their non-editor command line. Shall I try sed? Put sudo before the command, to elevate privileges.
      • sync, and reboot. The bit should be turned on.
      • Repeat vcgencmd and make sure the correct output is produced. Yes the bit is set.
      • Again edit /boot/config.txt and remove the program_usb_boot_mode=1 line (optional).
      • Done with this image; do systemctl poweroff.

      The SuSE instructions divert you at this point, but say that if the USB stick doesn't boot, continue in the Raspbian instructions to put the Raspbian image on it. I'm going to be anally retentive and will do that step now. Just like on a SD card, write the decompressed image directly to the raw device, being very careful to get the correct one.

      RPi power off. Remove the SD card. Insert the USB stick. Power on. Success, it boots! It had to reboot at least once, after expanding the root partition, which it didn't do with the SD card. It showed the rainbow splash screen, which didn't happen with the Raspbian SD card or any of the SuSE images.

      Major step 2: Stuff your USB drive with a SuSE system.

      This assumes that you have a Raspberry Pi that you can boot into OpenSuSE. The most likely candidate is the one you just made USB bootable, but actually booting it from its SD card. It will boot from the first device on which it can find bootcode.bin, and the SD card is checked first. Boot it up.

      Make sure that recent instances of packages raspberrypi-firmware and raspberrypi-firmware-config are installed. Do zypper install raspberrypi-firmware raspberrypi-firmware-config. It will install the most recent version, or will tell you if you already have the most recent version.

      Identify the USB stick. Commonly but not always, it will be /dev/sda. Warning: be very sure to correctly identify the drive that you are going to overwrite. Pre-create your partitions. (See the Howto for parted commands.) The Howto says to create a MBR/MSDOS partition table, but other forum posts say that the boot ROM can interpret a GPT as well, and I'm going to try that. Also, the EFI (boot) partition doesn't have to be first; a grub-boot partition may come first. Typical sizes for a RPi with 1Gb of memory:

      • Grub-boot: 1Mb, type=00, unformatted
      • EFI: 40Mb, type=0c, fat32
      • Swap: 1Gb, type=83 (equal to memory)
      • Root: 31Gb, type=82, ext4
      Jimc likes to mount partitions by label.

      Parted commands:
      unit MiB # 2^20 bytes
      mktable gpt
      mkpart primary 0 1MiB #Moves start to sector 34, it complains about misalignment. This is irrelevant on flash memory. Accept/ignore both.
      mkpart primary fat32 1MiB 41MiB
      mkpart primary linux-swap 41MiB 1GiB
      mkpart primary ext4 1GiB -1s #The latter means to end of disc. It doesn't like that; it shortens by 33 sectors. Accept.

      Create filesystems.
      /dev/sda1 (grub-boot) does not get formatted.
      mkfs.vfat -n PI1-EFI /dev/sda2
      mkswap -L PI1-SWAP /dev/sda3
      mkfs.ext4 -L PI1-ROOT /dev/sda4

      Clone the running operating system onto the USB stick.
      mount /dev/sda2 /mnt
      rsync -ax /boot/efi/ /mnt/
      umount /dev/sda2
      mount /dev/sda4 /mnt
      rsync -ax / /mnt/
      # (Don't) umount /dev/sda4

      Bind-mount /dev /sys /proc into /mnt, then chroot /mnt.

      Edit /etc/default/grub to have the new root device, and turn off OS_PROBER. The root filesystem can be identified by label or by UUID. grub2-mkconfig -o /boot/grub2/grub.cfg

      Edit /etc/fstab to use the new USB partitions.

      Edit /etc/dracut.conf.d/raspberrypi_modules.conf to add USB drivers to be included in the initrd. Execute mkinitrd .

      Exit from the chroot jail and un-do the bind mounts. Unmount the USB stick. Poweroff. Remove the SD card. Power on.

      Easier way to create a bootable USB stick

      Starting about 2017-03-01, at least for Tumbleweed, the images should be bootable out of the box. Just copy them to a USB stick. Index of the aarch64 images (64bit). (Images are also available for arm7l (32bit).) Images are available specialized for a wide range of ARM boards including Raspberry Pi and EFI(?), and also Chromebook in arm7l architecture. There are variants for E20 (not sure what this is), Gnome, JeOS, KDE, LXQT, X11, XFCE.

    Outtake: Details of One of the Various Installations

    Details of Installation:

    An off-topic tidbit: If IPv6 won't appear, check if Orion has gotten a generic DHCP address rather than its assigned address, which dnsmasq hands out by DHCP. If so, kill wickedd-dhcp6, remove lease-eth0-dhcp-ipv6.xml, and restart wicked. Just restarting wickedd-dhcp6 is not enough, probably because wickedd-nanny remembers the lease.

    Outtake: More Testing: Sound

    It turns out that the key to making sound work is dtparam=audio=on in /boot/efi/extraconfig.txt .

    Picking up with testing after about a two month hiatus.

    Outtake: GPT Partition Table


    Trying again to boot the SuSE installer. This is the Tumbleweed DVD on USB. Silence. Trying again with no memory. Silence again. Trying with memory, but wiped. Still dead. Web research reveals that UEFI booting on Raspberry Pi is very experimental, and I think the installer uses UEFI. Let's forget about UEFI for a while. Also /kiwi-hooks/preCallInit.sh says that Raspberry Pi firmware can't read a GPT and the script will use gdisk to switch it to MBR/MSDOS. So this whole approach is probably hopeless until somebody makes a big advance in the boot scripts.

    Raspberry Pi® Logo
    Photo and Image Credit