The most advanced custom firmware for the Spotify Car Thing - Restore functionality to your Spotify Car Thing!
No followers yet
Once you ship this you can't edit the description of the project, but you'll be able to add more devlogs and re-ship it as you add new features!
I completely forgot about Summer of Making, but a large amount of progress has been made. Full communication between the mobile app and daemon over Apple ExternalAccesory is working now, and we will soon start work on the Android app (this will use standard rfcomm with the daemon).
So much work happened, we started working on a mobile app while we develop an iAP2 compatible backend. The Spotify Car Thing has an MFi chip, so it is theoretically possible to reuse it for iAP2. UI is not great for now but it'll be worked on more later!
Currently just working on a basic dashboard for 3.1.0 to make authorizing with Spotify a little easier and fix some token refresh bugs we were having (the eMMC on the Car Thing isn't great and sometimes has trouble saving data on power losses, which happens when a car is shut off, for example).
Sorry for the lack of dev logs, but it is finally done. It has been tested thoroughly, thanks to our supporters, and we are proud to say that we have the most advanced Car Thing custom firmware, and the only one that supports almost everything that Spotify's firmware had.
My most proud feature with Nocturne is in a feature called Nocturne Connector. The Car Thing does not have Wi-Fi, and Bluetooth tethering is low bandwidth and annoying outside of car use. In the past, you could run a script on a Raspberry Pi to use USB tethering with the Pi connected to your network and handling NAT.
I wanted to automate this. My idea started as a read-only rootfs flashable image to put on the SD card, and that was a good idea, but another Nocturne developer suggested booting the Pi from the Car Thing's USB gadget. This surprisingly... was not a crazy idea and even works well.
From a section I wrote in the Connector README, "Nocturne Connector uses a specially crafted Alpine initramfs. Your Car Thing is configured as a USB gadget for both USB networking and mass storage. The mass storage part is how the Pi can boot off of it.
When a Raspberry Pi 4 or 5 (and newer!) boots, it first looks for an SD card, and if there isn't one, it'll fall back to USB boot. This will power up all USB devices and wait for one to show some sort of boot medium. This works in our favor because we can have a zero config Pi boot filesystem that is stored on the Car Thing.
Inside connector.img, there is a standard Pi boot filesystem, but there is no root partition. The rootfs is stored in initramfs.cpio.zst on the boot filesystem, and the Pi is told to use that to boot inside config.txt. Typically, on a traditional Linux system, the initramfs is used to prepare the system, such as decrypt and/or mount filesystems, but we can use it here as a read-only filesystem to boot from, as we aren't required to store any data on it."
In the video, you can see that (over UART for logging) the Pi bootloader starts, detects that there's no SD card, and powers on all USB devices and waits for bootable medium. The modded Car Thing has a USB gadget service which attaches the mass storage device, and the Pi will detect it and boot the initramfs declared in config.txt.