That reminds me of a three week, three person group project I had back when I was in university. There were a couple of topics we could pick from, including writing a very simple operating system from scratch. I asked the professors if we could instead port MINIX3 to the Raspberry Pi (given that it already had an ARM port to the BeagleBoard) and they accepted.
What was supposed to be a reasonably straightforward project proved to be a huge challenge as we encountered numerous unforeseen technical difficulties. One particularly harrowing one was that the Raspberry Pi 3 booted into hypervisor mode instead of supervisor mode and QEMU's Raspberry Pi emulation accuracy was so abysmal back then to be borderline useless for osdev. I recall it took me an entire week of low-level hardware debugging just to figure that one out.
By the end, we pulled through and delivered a working port with UART, GPIO and framebuffer drivers that could run on the Raspberry Pi 2 and 3. We run our presentation with the port on real hardware, using a shell script that displayed bitmaps from the ramdisk and monitored GPIO pins to move slides forwards or backwards (I used a knife to short-circuit the pins as needed). It was by far the coolest presentation of all the groups just on originality alone and I think I still have the image of that SD card somewhere.
Maybe, but I already had a reputation of being the dark wizard back then. If anything, the other students in my group went along with this because they knew I could overcome any problem... regardless of the cost on my sanity.
> How did you handle the debugging the raspberry pi on real hardware?
Painfully through serial output. I didn't have access to a JTAG probe at the time (I'm not even sure the Raspberry Pi could be debugged that way) and documentation was exceedingly poor.
After that experience, I refuse to debug anything hardware-related without at the very least a GDB stub.
This is Broadcom we're talking about, where that's par for the course. Personally I'd choose a SoC from AllWinner or Rockchip or even Mediatek over them.
> I didn't have access to a JTAG probe at the time (I'm not even sure the Raspberry Pi could be debugged that way)
The BCM2835-based ones can - I don't know about the modern ones - but you have to change the configuration on a couple of GPIOs to make it show up. (Which makes it difficult to debug early startup, unfortunately.)
> I used a knife to short-circuit the pins as needed
Reminds me of shorting the two power-on pins on an ATX motherboard to start it without a switch installed. Obviously, your setup was far cooler. Nice work.
That lasted a few months for me, until I found a box of the front panel connectors, and I taped together a power/reset and speaker connector. ( I made two, one to use, and one as a spare... ) after not being used for 6 months, It got tossed... of course, only to be needed a few years later for fixing a intermittent motherboard.
We did this sort of thing at SFU some 25-30 years ago; though we stopped short of running an OS and compiler on it, and it wasn't a group project.
For those interesting in trying this sort of experiment, but wish to have some guidance and accessible tooling, I highly recommend Turing Complete; you'll go from a few gates to a full computer. Components can be shared with the community; where you'll find things like a RiscV core and such. Anyhow, it's great fun. Do recommend. It's on Steam:
It still to this day has a thriving scene, lots of interesting quirky programs still being written for it. (https://oric.org/)
There is also a thriving hardware hacking scene of course, 21st century peripherals being brought to the user base, and so on.
One of the more interesting things (besides LOCI), is the orix system, which is a 'unix-like' environment for the Oric, which uses avariant of the 6502 cpu.
Its pretty cool - and fun if you're an Oric nerd - but if you like 'unix-like' systems for unusual platforms, put this one in your list to check out, as well:
Oh, yeah, I know 'unix-like' has a wide scale of sincerity, this is not quite there .. yet .. in terms of having all the unix bits, really .. but it is at least bootstrap in that kind of direction, for the Oric .. anyway ..
LOL in my 4th year Advanced Operating Systems Concepts course we wrote a toy x86 OS from scratch. We obviously didn't have to make our own hardware, but uhhhh I definitely added a bunch of printfs inside QEMU to dump out CPU states when we couldn't figure out the chain of events that led to hard faults.
On the other side... have also definitely used a pair of LEDs to try to debug an RTOS on a microcontroller with no JTAG access...
This reminds me of a kind of similar academic(?) project that at the very least had a custom C compiler alongside a custom OS… I can’t remember what it is offhand though.
Maybe I missed it but which FPGA did they use for this? I’m interested in learning FPGAs but there doesn’t seem to be a lot of freewheel documentation or software out there, it’s mostly vendor locked. I’m spoiled by the availability of STM32, AT, TI, etc MCUs and how easy it is to kludge things together.
That reminds me of a three week, three person group project I had back when I was in university. There were a couple of topics we could pick from, including writing a very simple operating system from scratch. I asked the professors if we could instead port MINIX3 to the Raspberry Pi (given that it already had an ARM port to the BeagleBoard) and they accepted.
What was supposed to be a reasonably straightforward project proved to be a huge challenge as we encountered numerous unforeseen technical difficulties. One particularly harrowing one was that the Raspberry Pi 3 booted into hypervisor mode instead of supervisor mode and QEMU's Raspberry Pi emulation accuracy was so abysmal back then to be borderline useless for osdev. I recall it took me an entire week of low-level hardware debugging just to figure that one out.
By the end, we pulled through and delivered a working port with UART, GPIO and framebuffer drivers that could run on the Raspberry Pi 2 and 3. We run our presentation with the port on real hardware, using a shell script that displayed bitmaps from the ramdisk and monitored GPIO pins to move slides forwards or backwards (I used a knife to short-circuit the pins as needed). It was by far the coolest presentation of all the groups just on originality alone and I think I still have the image of that SD card somewhere.
Nice.
> I asked the professors if we could instead port MINIX3 to the Raspberry Pi
I think they were expecting you to fail.
> QEMU's Raspberry Pi emulation accuracy was so abysmal
When I did some hobby OS dev my strategy was to make it work on QEMU and then pray it would work on real hardware as well, which worked OK...
How did you handle the debugging the raspberry pi on real hardware?
> I think they were expecting you to fail.
Maybe, but I already had a reputation of being the dark wizard back then. If anything, the other students in my group went along with this because they knew I could overcome any problem... regardless of the cost on my sanity.
> How did you handle the debugging the raspberry pi on real hardware?
Painfully through serial output. I didn't have access to a JTAG probe at the time (I'm not even sure the Raspberry Pi could be debugged that way) and documentation was exceedingly poor.
After that experience, I refuse to debug anything hardware-related without at the very least a GDB stub.
and documentation was exceedingly poor.
This is Broadcom we're talking about, where that's par for the course. Personally I'd choose a SoC from AllWinner or Rockchip or even Mediatek over them.
> I didn't have access to a JTAG probe at the time (I'm not even sure the Raspberry Pi could be debugged that way)
The BCM2835-based ones can - I don't know about the modern ones - but you have to change the configuration on a couple of GPIOs to make it show up. (Which makes it difficult to debug early startup, unfortunately.)
> I used a knife to short-circuit the pins as needed
Reminds me of shorting the two power-on pins on an ATX motherboard to start it without a switch installed. Obviously, your setup was far cooler. Nice work.
That lasted a few months for me, until I found a box of the front panel connectors, and I taped together a power/reset and speaker connector. ( I made two, one to use, and one as a spare... ) after not being used for 6 months, It got tossed... of course, only to be needed a few years later for fixing a intermittent motherboard.
I don't understand why Minix3 is not developed any more. I thought with Risc-V it would see a renewed interest.
I've ranted previously on that topic [1] [2] [3], but as a former contributor MINIX3 in my opinion is a technological dead-end that ran out of steam.
[1] https://news.ycombinator.com/item?id=41673634
[2] https://news.ycombinator.com/item?id=40762110
[3] https://news.ycombinator.com/item?id=34916261
We did this sort of thing at SFU some 25-30 years ago; though we stopped short of running an OS and compiler on it, and it wasn't a group project.
For those interesting in trying this sort of experiment, but wish to have some guidance and accessible tooling, I highly recommend Turing Complete; you'll go from a few gates to a full computer. Components can be shared with the community; where you'll find things like a RiscV core and such. Anyhow, it's great fun. Do recommend. It's on Steam:
https://store.steampowered.com/app/1444480/Turing_Complete/
That looks like the game-version of nand2tetris which I enjoyed doing a while back too (as another suggestion).
One of my favourite 8-bit computers of the era is the Oric-1/Atmos micro.
https://en.wikipedia.org/wiki/Oric_(computer)
It still to this day has a thriving scene, lots of interesting quirky programs still being written for it. (https://oric.org/)
There is also a thriving hardware hacking scene of course, 21st century peripherals being brought to the user base, and so on.
One of the more interesting things (besides LOCI), is the orix system, which is a 'unix-like' environment for the Oric, which uses avariant of the 6502 cpu.
Its pretty cool - and fun if you're an Oric nerd - but if you like 'unix-like' systems for unusual platforms, put this one in your list to check out, as well:
https://orix.oric.org
https://orix.oric.org/twilighte-board-v0-6-user-manual/
Oh, yeah, I know 'unix-like' has a wide scale of sincerity, this is not quite there .. yet .. in terms of having all the unix bits, really .. but it is at least bootstrap in that kind of direction, for the Oric .. anyway ..
Magic-1 and BMOW did similar, a while back. See: https://www.homebrewcpu.com/
The actual list of sites who have built their own CPUs: https://www.homebrewcpuring.org/
Very impressive! Low end work is often tedious and time consuming, especially if you lack the essentials like a debugger.
Until you've used an oscilloscopes to debug your buggy kprintf, you haven't lived.
LOL in my 4th year Advanced Operating Systems Concepts course we wrote a toy x86 OS from scratch. We obviously didn't have to make our own hardware, but uhhhh I definitely added a bunch of printfs inside QEMU to dump out CPU states when we couldn't figure out the chain of events that led to hard faults.
On the other side... have also definitely used a pair of LEDs to try to debug an RTOS on a microcontroller with no JTAG access...
"couldn't figure out the chain of events that led to hard faults..."
Tales from the terminal/dark side/h4x0r pro in da house!
First thing to do is get a working UART.
First thing to do is get a GPIO pin or two to toggle. Plenty of debug patterns that one can blink out.
Previously:
https://news.ycombinator.com/item?id=24680109
This reminds me of a kind of similar academic(?) project that at the very least had a custom C compiler alongside a custom OS… I can’t remember what it is offhand though.
(2020)
I wish I could do something like this.
Now they gotta run to the semiconductor lab and get them to fabricate the CPU instead of configuring an FPGA to run it.
TinyTapeout is right there to help you do that
[dead]
Maybe I missed it but which FPGA did they use for this? I’m interested in learning FPGAs but there doesn’t seem to be a lot of freewheel documentation or software out there, it’s mostly vendor locked. I’m spoiled by the availability of STM32, AT, TI, etc MCUs and how easy it is to kludge things together.