The curious case of 'ìe°[^]├UëÕ]Ús   UëÕâýj'

 firedrake, debugging, programming

11 months ago was the last time I touched firedrake, and last weekend the urge to mess with it caught me again. So I set up WSL, installed all necessary dependencies and opened firedrake. I fired up the last compiled version I had, just to remind myself of where I had left things, and I QEMU was happy to dump my debug printf()'s via the virtual UART into stdout. All was good. Then I compiled firedrake from scratch and it stopped working, or rather, it stopped producing output via the UART. That's strange, I thought, messed with a couple of things and also stashed all my git changes but no avail; No more output via the UART.Alright, debugger

Firedrake memory corruption bug

 programming, firedrake, debugging

There was a bug that I couldn’t figure out for the life of me. It was somewhere deep in my hobby kernel Firedrake and it made zero sense. It manifests as memory corruption, more specifically, at some point a pointer suddenly becomes zero. I tried to narrow it down with printf() debugging, but that didn’t get me very far because at that point the scheduler is already running and regular task switches occur, which have the side effect of the kernel not running in consecutive order any longer. Luckily, QEMU, my go to emulator, has support for GDB. The easy solution is therefore to fire up GDB, attach it to the remote debugger exposed by QEMU and set

Firedrake and Intel Edison

 programming, firedrake

I'm back from a business trip to Nice and a lot of stress that has kept me busy since the end of October is slowly fading away, which means I can go back and actually start hacking on the Intel Edison. Which actually means that I'm going to polish up a lot of parts of Firedrake before actually turning around and attacking the Edison. It helps to have a solid foundation to bootstrap oneself with. Two things that are really high up on my bucket list for Firedrake are more independence from the BIOS and GRUB as booatloader, with eventual independence from the CPU architecture itself. For that I want to implement a system that allows compiling the kernel with

Intel Edison Progress

 programming, firedrake

So, progress report on my Edison adventure: I managed to get my own kernel on it and have U-Boot boot it, which in retrospect took way longer than it should have (I'm not good at computers and embedded). Now the next issue is that the Edison has a Watchdog that will automatically reset the board if the Kernel is not periodically pinging it. The whole thing works by doing IPC from the Atom to the Quark, and so now I'm going through the Linux patch that comes with the Edison SDK to figure out how the hell all of this is supposed to work. Oh, and the UART is of course PCI based, so no way of just "simply&

Intel Edison

 programming, firedrake

Received my Intel Edison today, super cute device that promises to be quite lovely (especially for me coming from an x86 background and having a hard time with the ARM on the Raspberry Pi). I especially love the super small form factor of the Edison, which makes some applications much more feasible than the Pi. I still want to port Firedrake to the Pi and have actually made quite a few changes to support different hardware personalities as well as CPU architectures. But the Edison appears to be the somewhat easier target given that Firedrake is x86 already and has support for SMP. If only I could figure out how to flash my own kernel onto the Edison, the documentation