Raspberry Pi And The Story Of SD Card Corruption

Tales of Raspberry Pi SD card corruption are available online by the fistful, and are definitely a constant in Pi-adjacent communities. It’s apparent that some kind of problems tend to arise when a Raspberry Pi meets an SD card – which sounds quite ironic, since an SD card is the official and recommended way of booting a Pi. What is up with all of that?

I can start with a history lesson. Back when Raspberry Pi launched in 2012 – which is now 10 years ago – there were SD card controller driver problems, which makes sense given the wide variety of SD cards available out there. They were verifiably fixed one by one at some point in time, as debugging goes, their impact decreased and bugs with individual cards got smoothed over. This is how the “Pi SD card corruption” meme was originally born; however, if the problems were to end there, so would the meme. Yet, tales of broken SD cards plague us to this day – way less severe than they were in the beginning, but pronounced enough that you’ll see people encounter them every now and then.

Over the years, a devoted base of Pi SD card haters has grown. Their demand has been simple – Raspberry Pi has to get an ability to boot from something else, in large part because of corruption reasons, but also undeniably because of speed and capacity/cost limitations of SD cards. Thanks to their demands and work, we’ve seen a series of projects grow from unofficial efforts and hacks into officially supported Raspberry Pi abilities – USB boot being initially more of a workaround but now something you can enable out of the box, SSD-equipped Pi enclosures becoming more of a norm, and now, NVMe boot appearing on the horizon. Every few years, we get a new way to boot a Pi. Continue reading “Raspberry Pi And The Story Of SD Card Corruption”

Kia Recalls Cars Over Airbag Controller Assembly Issue

Last month Kia Motors announced a large recall due to possibly defective airbag controller units (ACU). The recall spans many models and model years — in the United States alone it covers over 400K cars, and over half a million cars worldwide. From the NHTSA report we learn that the problem happened at assembly when the cover of some ACUs interfered with the pins of an EEPROM chip. This can cause some of the pins to open-circuit. If your car had this problem, a warning light would come on, but more seriously, the airbags would not deploy in an accident. Kia estimates that less than 1% of the cars using this ACU have this issue. Cars which have this fault will get a new ACU, and other cars will get a firmware upgrade to keep this from happening should the EEPROM pins break loose in the future.

We think this EEPROM is used for logging errors and crash events, and is therefore not in the critical path for airbag deployment. The original firmware apparently prevented deployment if the EEPROM had a fault. Presumably, after this patch, if pins break in the future, the fault indicator still lights up but you’ll have functioning airbags.

It’s not clear if these broken EEPROM pin solder joints were present from the start and the factory test procedures didn’t catch the problem. Or did the pins left the factory intact and were subsequently broke due to bumps and vibrations. Hardware issues aside, having safety critical firmware perform its primary function even when faults exist in non-essential parts of the circuit seems like a requirement that should have been applied to the ACU from the beginning.

This is a reminder of the importance of enclosure design and making sure your PCB layouts take into account all clearances necessary for the entire assembly. How many times have you got your PCB back and realized you forgot to even put mounting holes?

We covered a similar issue a couple of years ago regarding the Takata airbag fiasco. If you have a Kia, this form on their website tells you whether your vehicle is subject to the recall or not.

Modern CPUs Are Smarter Than You Might Realize

When it comes to programming, most of us write code at a level of abstraction that could be for a computer from the 1960s. Input comes in, you process it, and you produce output. Sure, a call to strcpy might work better on a modern CPU than on an older one, but your basic algorithms are the same. But what if there were ways to define your programs that would work better on modern hardware? That’s what a pre-print book from [Sergey Slotin] answers.

As a simple example, consider the effects of branching on pipelining. Nearly all modern computers pipeline. That is, one instruction is fetching data while an older instruction is computing something, while an even older instruction is storing its results. The problem arises when you already have an instruction partially executed when you realize that an earlier instruction caused a branch to another part of your code. Now the pipeline has to be backed out and performance suffers while the pipeline refills. Anything that had an effect has to reverse and everything else needs to be discarded.

That’s bad for performance. Because of this, some CPUs try to predict if a branch is likely to occur or not and then speculatively fill the pipeline for the predicted case. However, you can structure your code, for example, so that it is more obvious how branching will occur or even, for some compilers, explicitly inform the compiler if the branch is likely or not.

As you might expect, techniques like this depend on your CPU and you’ll need to benchmark to show what’s really going on. The text is full of graphs of execution times and an analysis of the generated assembly code for x86 to explain the results. Even something you think is a pretty good algorithm — like binary search, for example, suffers on modern architectures and you can improve its performance with some tricks. Actually, it is interesting that the tricks work on GCC, but don’t make a difference on Clang. Again, you have to measure these things.

Probably 90% of us will never need to use any of the kind of optimization you’ll find in this book. But it is a marvelous book if you enjoy solving puzzles and analyzing complex details. Of course, if you need to squeeze those extra microseconds out of a loop or you are writing a library where performance is important, this might be just the book you are looking for. Although it doesn’t cover many different CPUs, the ideas and techniques will apply to many modern CPU architectures. You’ll just have to do the work to figure out how if you use a different CPU.

We’ve looked at pieces of this sort of thing before. Pipelining, for example. Sometimes, though, optimizing your algorithm isn’t as effective as just changing it for a better one.