Remove devices left after kpartx

In case you’ve used kpartx -a on a disk image to mount partitions from it, and then deleted that image (so you cannot kpartx -d anymore, as you would normally do), use this:

dmsetup delete /dev/dm-X

to remove each /dev/dm-X device left over. Use losetup -D to remove the /dev/loopX device left over.

ili9225 and fbtft

I was working on making an ILI9225-based display breakout work with the fbtft drivers. Here’s a page with pics for the exact make of the display breakout I worked with. Here’s a page that claims you can use ILI9341 fbtft commandline – except it’s an obvious copy-paste, the init commands of ILI9341 aren’t even close to what’s needed, and the register width is wrong – register addresses for ILI9225 are 1 byte and not 2 bytes wide, you should be able to verify that with a $6 logic analyzer (and if you don’t have one, buy one ASAP), and it should use the “0x20, 0x21, 0x22” addr set mechanism instead of something like “0x2A, 0x2B, 0x2C”. With a logic analyzer, Pulseview and a working C ILI9225 library for RPi that we could test against, we sat down and analyzed the behaviour of the library.

DSCN7335.JPGOur work setup


RPi with the display and the splitter


The splitter that allowed us to connect a logic analyzer in a clean way


Looking at the known-working data from the C library

We had to lower the SPI clock line – at 16MHz, the “Saleae clone” can’t keep up with 4 channels of data (CS, CLK, MISO and RS). It’s only useful to scope RST in the beginning – just to make sure it works. The SPI decoder worked wonders, even on a netbok with Intel Celeron 847 and 3GB of RAM (long live zram).

6 hours later, here’s a commandline that worked for us in the end, something that creates a framebuffer device that works with fbcp, con2fbmap and fbi:

sudo modprobe flexfb width=220 height=176 regwidth=8 init=-1,0x01,0x01,0x1C,-1,0x02,0x01,0x00,-1,0x03,0x10,0x30,-1,0x08,0x08,0x08,-1,0x0C,0x00,0x00,-1,0x0F,0x08,0x01,-1,0x20,0x00,0x00,-1,0x21,0x00,0x00,-2,50,-1,0x10,0x0A,0x00,-1,0x11,0x10,0x38,-2,50,-1,0x12,0x11,0x21,-1,0x13,0x00,0x66,-1,0x14,0x5F,0x60,-1,0x30,0x00,0x00,-1,0x31,0x00,0xDB,-1,0x32,0x00,0x00,-1,0x33,0x00,0x00,-1,0x34,0x00,0xDB,-1,0x35,0x00,0x00,-1,0x36,0x00,0xAF,-1,0x37,0x00,0x00,-1,0x38,0x00,0xDB,-1,0x39,0x00,0x00,-1,0x50,0x04,0x00,-1,0x51,0x06,0x0B,-1,0x52,0x0C,0x0A,-1,0x53,0x01,0x05,-1,0x54,0x0A,0x0C,-1,0x55,0x0B,0x06,-1,0x56,0x00,0x04,-1,0x57,0x05,0x01,-1,0x58,0x0E,0x00,-1,0x59,0x00,0x0E,-2,50,-1,0x07,0x10,0x17,-3 buswidth=8 setaddrwin=1 && sudo modprobe fbtft_device debug=3 name=flexfb rotate=1 speed=16000000 regwidth=8 buswidth=8 gpios=reset:25,dc:24,led:18,cs:8

There’s probably an easier way to do that – please leave a comment if you find one!

Here’s a picture you can use with fbi in your testing:

you can do wget to download this picture from command-line. Use imagemagick to rotate it if necessary.

The flexfb driver is getting removed from the kernel. You should be able to compile it in again – revert this commit and then just go as you’d go about compiling kernel modules, here’s an example for the sh1106 module.

Also, here’s the datasheet. Here’s a mirror of it: Datasheet_ILI9225DS_V022   

The datasheet is good enough as far as datasheets go. For example, in case you need to flip the display (as we did), it’s easy to find that you need to flip the bits in the 0x01 register – to test that on-the-fly, just run

sudo modprobe -r fbtft_device && sudo modprobe -r flexfb

and rerun the init command tweaking the registers that you need, no need to even restart.

Convert .CAP file into a BIOS (UEFI) image you can use with an SPI programmer

So, you got a .CAP file and you want to flash over SPI. CAP file format is a universal format for sharing UEFI BIOS images that people can program through a BIOS menu, DOS prompt, or using a manufacturer-approved flash tool – some manufacturers are using this format already, let’s hope it catches on since finally having some standards is good. What if your motherboard’s BIOS is already dead or doesn’t support the CPU you’re trying to boot with, though? You need to boot the computer to flash a new .CAP, however, you can’t boot your computer until you flash that .CAP. You can use an SPI programmer to flash it, all using free and open-source software (flashrom) – on the hardware side, a Raspberry Pi will work, so will a CH341-based programmer from eBay. I use my Pi Zero-powered ZeroPhone for this since it already has all the tools and breaks out all the SPI pins needed.

But first, you need to extract the firmware file from the .CAP file. You can do that through Linux command-line:

dd bs=1024 skip=2 if=YOURFILE.CAP of=image.bin

Some insight:

root@zerophone-prototype:/home/pi/z370# ls
190701-first.bin TUF-Z370-PRO-GAMING-ASUS-2102.CAP
# "first" is a working BIOS image dumped from the SPI flash
# let's run dd on the .CAP file
root@zerophone-prototype:/home/pi/z370# dd bs=1024 skip=2 if=TUF-Z370-PRO-GAMING-ASUS-2102.CAP of=trimmed.bin
16384+0 records in
16384+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.922419 s, 18.2 MB/s
# trimmed file size in bytes
root@zerophone-prototype:/home/pi/z370# du -B1 trimmed.bin
16777216        trimmed.bin
# original file size in bytes
root@zerophone-prototype:/home/pi/z370# du -B1 190701-first.bin
16781312        190701-first.bin
# the CAP file size
root@zerophone-prototype:/home/pi/z370# du -B1 TUF-Z370-PRO-GAMING-ASUS-2102.CAP
16785408        TUF-Z370-PRO-GAMING-ASUS-2102.CAP
# Interesting, the trimmed image is said to be 8192 bytes smaller than .CAP.
# Also, it's said to be 4096 bytes smaller than the original image
# Can we trust the du output here?
# Let's strip 3 blocks instead of 2 and check.
root@zerophone-prototype:/home/pi/z370# dd bs=1024 skip=3 if=TUF-Z370-PRO-GAMING-ASUS-2102.CAP
16383+0 records in
16383+0 records out
16776192 bytes (17 MB, 16 MiB) copied, 0.818545 s, 20.5 MB/s
root@zerophone-prototype:/home/pi/z370# du -B1 3.bin
16777216        3.bin
# I guess the answer is no.
# Let's check the signature, at least?
root@zerophone-prototype:/home/pi/z370# xxd 190701-first.bin | head
00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000010: 5aa5 f00f 0300 0400 0802 105a 3003 3100  Z..........Z0.1.
00000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000030: f500 5c12 2142 60ad b7b9 c4c7 ffff ffff  ..\.!B`.........
00000040: 0000 0000 8002 ff0f 0300 7f02 0100 0200  ................
00000050: ff7f 0000 ff7f 0000 ff7f 0000 ff7f 0000  ................
00000060: ff7f 0000 ff7f 0000 ffff ffff ffff ffff  ................
00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000080: 000f a000 000d 4000 0009 8000 0000 0000  ......@.........
00000090: 0001 0110 0000 0000 ffff ffff ffff ffff  ................
# This has the proper binary image signature. What about the trimmed file?
root@zerophone-prototype:/home/pi/z370# xxd trimmed.bin |head
00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000010: 5aa5 f00f 0300 0400 0802 105a 3003 3100  Z..........Z0.1.
00000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000030: f500 5c12 2142 60ad b7b9 c4c7 ffff ffff  ..\.!B`.........
00000040: 0000 0000 8002 ff0f 0300 7f02 0100 0200  ................
00000050: ff7f 0000 ff7f 0000 ff7f 0000 ff7f 0000  ................
00000060: ff7f 0000 ff7f 0000 ffff ffff ffff ffff  ................
00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000080: 000f a000 000d 4000 0009 8000 0000 0000  ......@.........
00000090: 0001 0110 0000 0000 ffff ffff ffff ffff  ................
# Looks like we have what we need!

du issues notwithstanding, this file, once flashed into the chip using an SPI programmer, actually booted the motherboard. For a good measure, I then used the BIOS built-in flasher tool to flash the .CAP over this file, just in case there are actually some differences.

Warning: if the motherboard works (i.e. you just can’t boot it using the current CPU and you don’t have another CPU), please dump the original flash image before proceeding. Another warning: you might lose your MAC address, but there are tutorials available showing you how to add it, and there are also tutorials showing how to extract it from the original image if you need that.

Interested to know more about .CAP format? This article helped me a lot, it’s in Russian, so if you don’t know it, use your online/browser-builtin translation service of choice.

Installing Replicant 4.2 on Galaxy S1

Yesterday, I decided to install Replicant on a Samsung Galaxy S1 ( i9000, also referred to as galaxysmtd in the builds ). However, it already had some version of Cyanogen Mod on it – apparently, not the one that was installed. Also, I had to blacklist some drivers for heimdall tool to work on my Linux laptop.

When flashing recovery – if you connect a Galaxy S1 in download mode to a Linux laptop, it’ll present itself as a serial port, then the cdc_acm driver will load and, apparently, send some AT commands (to check if the device is a modem), which crashes something in the download mode code, apparently, so it stops responding to the heimdall tool and there’s always this “Protocol initialization failed” message, and if you get further, there are still problems

To solve this, I added two lines: “blacklist cdc_acm” and “blacklist visor” to an /etc/modprobe.d/blacklist.conf file, and then rebooted. I don’t know if that could be solved without rebooting, only after reboot it seemed to be solved for me.

After this, I could easily flash Replicant-provided recovery image to the phone. However, it’d give this error all the time:


“Error in (Status 0)”. Not the most informative error message. Basically, the scripts returns “ran normally” but the install doesn’t continue. I opened the .zip and saw the there, which ought to have been the file causing that error. After debugging the script execution path with some ui_print macros, I found a section in the middle of the script (in the section for “new mtd layouts” or something) that would stop the process, but exit 0 (erroneously assuming something IIRC).  I removed that section, and it went further – but got stuck on some thing that would “exit 7”. I removed that exit statement too, and Replicant finally got installed. TODO: understand what that “exit 7” thing was complaining about.

However, Replicant is running great now, so all is well =)

Raspberry Pi audio jack part number

The part number for that black audio+video jack that can be seen on Raspberry Pi B+ / A+ / 2 / 3 is FC68125. I found it by accident, when I needed to source them for ZeroPhone, so I had to find the part number – and here it is =) I had to find it once again, and it appears it’s ungooglable, so I leave the part number here, hoping that it helps somebody in the future.

Disabling Raspberry Pi 3 WiFi via config.txt

Today, I had to quickly debug a Pi which had a problem – it’d kernel panic right after boot due to the WiFi driver. It was probably a software problem since it would only happen on that specific SD card – on any of the Pi 3 I have. I had to solve it quickly – and all the solutions on the internet involved editing files on the Pi ext4 filesystem. I couldn’t log in the Pi, since, well, kernel panic, and I couldn’t mount the ext4 FS because I didn’t have a Linux machine handy. I did have access to config.txt, though.

I finally found a solution on OSMC forums. The way to disable the interface that Pi uses to communicate with Broadcom WiFi is:


Insert that in config.txt and the WiFi is going to be ignored. It’s not a power-saving solution – I can’t be sure it actually turns the WiFi chipset off, but it does prevent the OS from detecting it.

SSD1332 65K 96×64 Color OLED sample code + pinout + simplest Eagle breakout

So, I’ve searched for this display’s files for two weeks. Those are cheap (3$ on eBay), but unlike all those SSD1332 displays with green ribbon of uniform width (and available drivers and breakouts). I’m not even sure if this display is SSD1332 based, and I’m not sure I care after many frustrating unsuccessful attempts to get it working. It’s cheap, however, but you do get a bare panel with a controller.

Apparently, these displays are produced by RiTDisplay. They weren’t that helpful with datasheets though and it’s not even listed on their page. Also, apparently, it’s discontinued now. The display has 27 pins, with SPI and 8-bit interface both available. I found it listed as RGS10096064FR004 on one site but the datasheet seemed to be behind the paywall.

Recently, I found the datasheet (more or less accessible), pinout information (found it before somewhere too, but it was hard) AND SAMPLE CODE! I haven’t yet checked it, but since it was hard to find, I’m sharing it with others.

Dropbox link

RGHost link

Yandex Disk link

Also, I’m sharing the simple board I’ve made in Eagle. It’s in no way complete –  no annotations, some jumpers might be missing for your purpose and you’ll have to check the pinout for your driving mode, but the FPC pitch is right and all the pins you’d need are broken out on headers. I also plan to transfer it to KiCad quite soon, so expect it to be available as well.




Yandex Disk

The sudo fraud

Ilya's blog

Dear systems engineers,

It really amazes me how people are fine with typing sudo all the time. A kitten is denied a new toy for another day when you do this!


Typing sudo locally all the time

Is it really simpler for you to type sudo all the time rather than having one terminal tab open with a root shell? Besides, some systems even ask for a password when you run a sudo command. Be honest with yourself, are you a masochist?

Using sudo on servers


Intro: each Amazon image comes with standard username for logging in. Never seen anyone changing that username.

Supposedly, the attacker would need to know the username in addition to your stolen private key. Right… and it’s not one of these: ubuntu, admin, ec2-user, centos … and looking at your ssh banner won’t give any clue as to which username is used:


View original post 220 more words