So I stumbled onto LiteBSD while I was trying to see if I can cross compile 386BSD 0.0 from Windows (it compiles, but triple faults on boot.)
LiteBSD is a 4.4 BSD derived OS for PIC32MZ microcontrollers.
So what about us poor Windows users?
Well a few tweeks, and only one annoying bug remains, but it’s easy enough to sidestep and it runs!
Even better, I got the console to kind of work, although you can still control+c it to kill Qemu. I guess I could capture the signal being kind of UNIXy.
For some reason when opening the SD card image, it’s already open by the time pic32_sdcard_init is called. Or so I suspect. It gets the file handle of 3 which tells me that it shouldn’t be open. So my fix is lame but it works. Since something is holding the file that I can’t see, I launch Qemu like this:
qemu-system-mipsel.exe -machine pic32mz-wifire -nographic -serial vc -serial vc -serial vc -serial mon:stdio -bios boot-wifire.hex -kernel vmunix.hex -hda litebsd.img
with the SD/HDA being litebsd.img but in pic32_sdcard_init I do this:
So you need a dummy file named litebsd.img (it’s just junk but it needs to exist), so whatever is blocking it will block it, then let pic32_sdcard_init open the file litebsd.img.SD which is the real file.
C:\litebsd>qemu-system-mipsel.exe -machine pic32mz-wifire -nographic -serial vc -serial vc -serial vc -serial mon:stdio -bios boot-wifire.hex -kernel vmunix.hex -hda litebsd.img
WARNING: Image format was not specified for ‘litebsd.img’ and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the ‘raw’ format explicitly to remove the restrictions.
Board: chipKIT WiFire
RAM size: 512 kbytes
Load file: ‘boot-wifire.hex’, 6916 bytes
Load file: ‘vmunix.hex’, 522408 bytes
sdcard: opened d->fd 3
Card0 image ‘litebsd.img’, 339969 kbytes
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
4.4BSD-Lite build 13 compiled 2015-01-20
cpu: PIC32MZ2048ECG100 rev A4, 200 MHz
oscillator: system PLL div 1:6 mult x50
real mem = 512 kbytes
avail mem = 344 kbytes
using 18 buffers containing 73728 bytes of memory
spi1 at pins sdi=D14/sdo=C1/sck=D1
spi2 at pins sdi=F0/sdo=D11/sck=G6
spi3 at pins sdi=B10/sdo=C4/sck=B14
spi4 at pins sdi=F5/sdo=G0/sck=D10
uart1 at pins rx=F1/tx=D15, interrupts 112/113/114
uart4 at pins rx=F2/tx=F8, interrupts 170/171/172, console
sd0 at port spi3, pin cs=C3
sd0: type I, size 339968 kbytes, speed 12 Mbit/sec
sd0a: partition type b7, sector 2, size 204800 kbytes
sd0b: partition type b8, sector 409602, size 32768 kbytes
sd0c: partition type b7, sector 475138, size 102400 kbytes
bpf: sl0 attached
bpf: lo0 attached
WARNING: preposterous clock chip time — CHECK AND RESET THE DATE!
starting file system checks.
/dev/rsd0a: file system is clean; not checking
standard daemons: update.
Wed Dec 10 21:06:39 PST 2014
4.4BSD-Lite (bsd.net) (tty4)
So there it is! As always, you can do the whole telnet console, on port 2023 like the SPARC with:
qemu-system-mipsel.exe -machine pic32mz-wifire -nographic -serial vc -serial vc -serial vc -serial mon:telnet:127.0.0.1:2023,server,wait -bios boot-wifire.hex -kernel vmunix.hex
In this case, I prefer to use the ‘wait’ portion of the server, so I can watch it boot. Maybe I’m just weird. But this way you can control+c to your hearts content.
As always, you can download my image here.
Also for those who like graphical serial connections (???) you can launch it like this:
qemu-system-mipsel.exe -machine pic32mz-wifire -serial vc -serial vc -serial vc -serial vc -bios boot-wifire.hex -kernel vmunix.hex -sd litebsd.img
And use control+alt and hunt around for s3, and you’ll have your console….. That you can’t paste into.
**EDIT I found out I forgot to link this with static libgcc so there were missing DLL’s. sorry, I’ve re-linked and now it’ll just work out of the box (tested with clearing my path on Windows 10). Next I need to add curses support.