Got a chance to play around with a SPIKE based game recently and wanted to pass along some details in case they're of any use. Basically, I made an image of the SD card and mounted said image on a Linux system to see what was there. Forgive me if these have been posted before, I hadn't found it in a quick search. Please note this assumes you have knowledge of Linux but I'll be happy to answer whatever I can.
NOTE: I am posting this simply out of interest for how these devices work and what can be done with them.
SD Card partition layout:
Disk Downloads/spike-orig.img: 3904 MB, 3904897024 bytes
100 heads, 35 sectors/track, 2179 cylinders, total 7626752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00018e69
Device Boot Start End Blocks Id System
Downloads/spike-orig.img1 * 35 6999 3482+ 1 FAT12
Downloads/spike-orig.img2 7000 13999 3500 da Non-FS data
Downloads/spike-orig.img3 14000 262499 124250 83 Linux
Downloads/spike-orig.img4 264192 7329791 3532800 5 Extended
Downloads/spike-orig.img5 266240 397311 65536 83 Linux
Downloads/spike-orig.img6 399360 6690815 3145728 83 Linux
Downloads/spike-orig.img7 6692864 6823935 65536 83 Linux
So basically what happens when you put this card in a normal Windows / Mac system is you only see the first partition of about 4MB in size even though the card is about 4GB. I haven't verified it, but the file on said partition is called BOOT.BIN. Most ARM based systems will boot off either SD/MicroSD or eMMC if equipped.
The interesting parts are the Linux partitions (3, 5, 6, 7.) They are attached as follows:
Partition 3 - Root partition (/) - 114M in size, of which about 27M in use.
Partition 5 - Data partition (/data) - 58M, 1.4M in use
Partition 6 - Games partition (/games) - 2.9GB, use varies based on game. This is where the actual game code (i.e., the .SPK you'd pull from Stern's website) resides.
Partition 7 - Dump partition (/dump) - 54M, 1.3M in use
Partition 2 I haven't looked specifically into yet, but I think this is where the kernel resides. The "update" script appears to copy some data there.
The fstab looks as follows:
# file systems to mount at boot
rootfs / auto defaults 1 1
/dev/mmcblk0p5 /data ext3 rw,sync,relatime,exec,data=
ordered 0 2
/dev/mmcblk0p6 /games ext3 ro,relatime,errors=continue
,exec 0 2
/dev/mmcblk0p7 /dump ext3 rw,relatime,errors=continue
,exec 0 2
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
usbfs /proc/bus/usb usbfs defaults 0 0
tmpfs /var/volatile tmpfs defaults 0 0
tmpfs /dev/shm tmpfs mode=0777 0 0
Kernel version: 2.6.30
Interesting kernel modules: amp, backlight, dmd, i2s, at91gpio, USB gadget drivers.
NOTE: Gadget drivers typically allow a system to act as another device over USB (ethernet, mass storage, serial port.) These may simply be a component of the base Linux system for the ATMEL ARM chip being used. But it would be particularly interesting to plug into an OTG port (I've only seen the topside of the SPIKE MPU - are there any mini/micro USB ports on the bottom?)
System shell is busybox based
Hostname is "pinball"
System starts in run level 2, has 3 startup scripts:
S20syslog (from what I have gathered so far, nothing is actually logged to the SD card. Good for life of SD card, not great for exploration. Easily modified.)
S95game (This is a particularly interesting script - it basically runs the game code and sets up everything of interest)
S99rmnologin (Simply removes the /etc/nologin file if present - this is a busy box script I believe)
For the S95game script, there's a lot here - I may go into more depth if interest. Some interesting pieces / theories:
/usr/local/bin/dprint - Looks like this will print a message to the display / DMD. This appears to be correct based on the "update" script referenced below.
There's a section on updating the "network bridge" - the Linux geek in me wants this to be Ethernet / etc, but I think this is actually the inter-module communication network between the MPU and the playfield area. It specifically mentions updating some of the AVR fuses (note: these have nothing to do with normal fuses) if needed. This could be related to the ATTINY4313 on the MPU near the ARM chip.
Logging is setup to go to a volatile memory area.
Once that's all setup, it basically runs /games/game (there's some monitoring / etc in there.) Note that as part of the game code, there is an update script that runs. It appears to check for the presence of the USB sticks and runs through the updates. It appears that linux kernel updates can be included along with game code updates.
All the binaries I've checked are compiled for 32bit ARM - I tried a quick chroot to see more details, but the architecture didn't match (this is expected - running on a normal Intel system.) I haven't had time yet to load this image on an ARM board and see if I can get more details.
As for what to do with this - right now, nothing. I'm mostly just exploring to see what's here. Given I don't have my own SPIKE based system to mess with, I'm not sure where this will go.
Some early thoughts:
- I get the feeling the OS is based off either an ATMEL reference distribution and / or some previous stuff Stern has used for development. I found an old bashrc file that referenced Transformers and Batman last updated in 2011. The aliases seem to indicate a development environment.
- From a hardware perspective, the card I had access to was a class 4 4GB card. If this is normal, it doesn't surprise me they had to update things to handle SD card weirdness (class 4 cards of this size are around $5 in single quantities. Class 10 cards are about $7.)
- If I had a system, I would likely make a copy of the image onto a larger card, perhaps make my own partition in the extra area, and setup logging to go there. Run a game or two and then see what came out on the logs. A few diagnostic commands wouldn't hurt either. The biggest trick is making sure the partition dismounts ok.
- Which brings up an interesting hardware point - when watching the machine, it appears to have caps that keep some power to the system for quite a while afterwards. Given some of the partitions are mounted RW, this could provide time to shutdown cleanly before offing the card.
- The game update code looks pretty interesting.
- Finally, I discovered the game updates do not include the OS itself. Kernel updates appear to be an option for updates but the actual OS isn't part of this. Basically, if (when) the SD cards crap out, they'll have to send out a whole new one to make things work. Just post an image file with basic instructions - people use Win32DiskImager to image Raspberry Pi's all the time. It'd be pretty simple to do the same on here.
Questions / Suggestions?