Raspberry Pi Zero W as IoT Bluetooth Gateway Part1: Installing Slackware

Power connector is micro USB on far right

I ordered in quick succession a NodeMCU ESP-12E and a Raspberry Pi Zero W. Both came very quickly but the Zero W got off the ground first.

I powered it using its micro USB socket (far right in above picture) with my favourite Slackware distribution in micro SD card, and nothing happened. It drew only 20-30mA current. I used a feisty 2A Samsung USB charger that put out 5.2V.

I had expected a little power LED at the very least. A little concerned I might have got a dud, I shorted the bare 'reset' PCB vias using a pair of steel tweezers.

'Reset' PCB vias (bottom left) marked 'RUN'

Again, nothing.  After 30 years of electronics you get used to having your blinkenlights, chief amongst them is your 'Power' LED.

The usual rats' nest

As a last resort, and just because I had a Sandisk Class 10 32GB microSD card, I loaded it with Ubuntu Mate, a recent Linux distribution for the Raspberry Pi B. And, bingo, after a few seconds I have my little green light. 

So instead of connecting a 'Power' LED directly to the power supply (usually in series with a current-limiting resistor) the designers must have used the CPU's GPIO pin to turn on the power LED. This kind of works, but makes it a little harder to troubleshoot power supply problems, and the Raspberry Pi has no shortage of those.

Nothing much happened after the power LED came on. No WiFi access point, no bluetooth device came up. Hmmm. I bought a mini HDMI adapter and hooked it up to my monitor and, aha, I have a 'kernel panic- Attempted to kill init!' message. Looks like Ubuntu Mate does not run on the Pi Zero W. This is confirmed by this handy article. Rather, the Pi Zero W (and its close relative the Zero) is compatible with the older Raspberry Pi A and A+.

Time to try my trusty Slackware 14.1 Raspberry Pi image. A few years ago I got Slackware running on the Raspberry Pi A by using an Ubuntu kernel with a Slackware root filesystem. I loaded it into my new microSD card, powered up, and nothing happened. No blinkenlight. Not even a kernel panic. Time to dig a little deeper.

A look at my Slackware image showed it consisted of 2 partitions, a Windows-type FAT32 boot partition and a much larger Linux ext4 root partition.

The Windows FAT32 boot partition looks like this:

$ls -l ../slackware/boot
total 31076
-rwxr-xr-x 1 root root     1447 Jan 19 15:29 LICENCE.broadcom
-rwxr-xr-x 1 root root     2013 Jan 19 15:29 README
-rwxr-xr-x 1 root root     1479 Jan 19 15:29 README.initrd
-rwxr-xr-x 1 root root   777094 Jan 19 15:29 System.map
-rwxr-xr-x 1 root root    16536 Jan 19 15:29 bootcode.bin
-rwxr-xr-x 1 root root       82 Jan 19 15:29 cmdline.txt
-rwxr-xr-x 1 root root       91 Jan 19 15:29 config.txt
-rwxr-xr-x 1 root root     5282 Jan 19 15:29 fixup.dat
-rwxr-xr-x 1 root root     2020 Jan 19 15:29 fixup_cd.dat
-rwxr-xr-x 1 root root      137 Jan 19 15:29 issue.txt
-rwxr-xr-x 1 root root  3112676 Jan 19 15:29 kernel.img
-rwxr-xr-x 1 root root  2104952 Jan 19 15:29 kernel_cutdown.img
-rwxr-xr-x 1 root root 16264692 Jan 19 15:29 kernel_emergency.img
-rwxr-xr-x 1 root root   275235 Jan 19 15:29 loader.bin
-rwxr-xr-x 1 root root  2011408 Jan 19 15:29 start.elf
-rwxr-xr-x 1 root root   523144 Jan 19 15:29 start_cd.elf
-rwxr-xr-x 1 root root      101 Jan 19 15:29 version-kernel_raspi.txt
-rwxr-xr-x 1 root root       92 Jan 19 15:29 version-raspi-boot.txt

And an ext4 Slackware 14.1 root partition:

$ls -l ../slackware/root
total 164
drwxr-xr-x  2 root root  4096 Jan 19 15:30 bin
drwxr-xr-x  2 root root  4096 Jan 19 15:30 boot
drwxr-xr-x 17 root root 69632 Jan 19 15:30 dev
drwxr-xr-x  3 root root  4096 Jan 19 15:30 doc
drwxr-xr-x 89 root root 12288 Jan 19 15:30 etc
drwxr-xr-x  6 root root  4096 Jan 19 15:30 home
drwxr-xr-x  7 root root  4096 Jan 19 15:30 lib
drwx------  2 root root  4096 Jan 19 15:30 lost+found
drwxr-xr-x 16 root root  4096 Jan 19 15:30 media
drwxr-xr-x 11 root root  4096 Jan 19 15:30 mnt
drwxr-xr-x  2 root root  4096 Jan 19 15:30 opt
drwxr-xr-x  2 root root  4096 Jan 19 15:30 proc
drwx--x---  9 root root  4096 Jan 19 15:30 root
drwxr-xr-x  2 root root  4096 Jan 19 15:30 run
drwxr-xr-x  2 root root 12288 Jan 19 15:30 sbin
drwxr-xr-x  2 root root  4096 Jan 19 15:30 srv
drwxr-xr-x  2 root root  4096 Jan 19 15:30 sys
drwxr-xr-t  5 root root  4096 Jan 19 15:30 tmp
drwxr-xr-x 20 root root  4096 Jan 19 15:40 usr
drwxr-xr-x 18 root root  4096 Jan 19 15:41 var

A quick look at the Ubuntu Mate image showed a similar organization, a FAT32 boot partition followed by a Linux ext4 root partition. The boot partition is:

$ls -l ../ubuntu_mate/flash
total 20432
-rwxr-xr-x 1 root root   18693 Jan 19 15:11 COPYING.linux
-rwxr-xr-x 1 root root    1494 Jan 19 15:11 LICENCE.broadcom
-rwxr-xr-x 1 root root   14273 Jan 19 15:11 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root   14010 Jan 19 15:11 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root   13964 Jan 19 15:11 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root   15356 Jan 19 15:11 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root   15992 Jan 19 15:11 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root   15350 Jan 19 15:11 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root   17932 Jan 19 15:11 bootcode.bin
-rwxr-xr-x 1 root root     223 Jan 19 15:11 cmdline.txt
-rwxr-xr-x 1 root root   36783 Jan 19 15:11 config.txt
-rwxr-xr-x 1 root root    6622 Jan 19 15:11 fixup.dat
-rwxr-xr-x 1 root root    2535 Jan 19 15:11 fixup_cd.dat
-rwxr-xr-x 1 root root    9753 Jan 19 15:11 fixup_db.dat
-rwxr-xr-x 1 root root    9753 Jan 19 15:11 fixup_x.dat
-rwxr-xr-x 1 root root 4130008 Jan 19 15:11 kernel.img
-rwxr-xr-x 1 root root 4231256 Jan 19 15:11 kernel7.img
drwxr-xr-x 2 root root    4096 Jan 19 15:11 overlays
-rwxr-xr-x 1 root root 2823396 Jan 19 15:11 start.elf
-rwxr-xr-x 1 root root  634532 Jan 19 15:11 start_cd.elf
-rwxr-xr-x 1 root root 4956996 Jan 19 15:11 start_db.elf
-rwxr-xr-x 1 root root 3906116 Jan 19 15:11 start_x.elf

In an old-fashioned desktop or laptop, the startup process is controlled by a non-volatile flash, eeprom or eprom program called the BIOS. The ARM CPU in the Pi has a much smaller BIOS and has the rest of it stored on the microSD card. Now since I got a kernel panic from Ubuntu Mate, this meant that the ARM CPU managed to load the kernel and run it, only to have the kernel fail later. Since it is the job of the BIOS to load the kernel, this mean my Ubuntu Mate image had the correct BIOS files.

This link provides a good summary: 

The boot sequence of the Raspberry Pi is basically this:

1. Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
2. Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
3. Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
4. start.elf loads kernel.img. It then also reads config.txt, cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at 0×100 & kernel @ 0×8000 If disable_commandline_tags is set it loads kernel @ 0×0 Otherwise it loads kernel @ 0×8000 and put ATAGS at 0×100
5. kernel.img is then run on the ARM.

The Ubuntu Mate image did not have loader.bin or bcm2835.dtb but it did have a kernel7.img in addition to the kernel.img file.  So I copied the files bootloader.bin, start.elf, kernel.img and kernel7.img over to my Slackware image, taking care to keep my Slackware config.txt and cmdline.txt. Since the Slackware image did not have any dtb files at all, I copied them as well.

Updated 2018-01-21. See next post for corrections to files list.

Now the image worked, and Slackware was able to start. A little problem is it did not recognize the WiFi hardware and its WiFi interface did not come up. But that is a problem for another post.

If you would like to run Slackware on your Raspberry Pi Zero or Zero W, leave me a comment in this blog post and I will put up the 8GB image for download.  

Happy Trails.