This week I just received a blue box.
No, not this kind of blue box!
The coding period of Google Summer of Code 2014(as well as the program itself) ended on Monday August 18, 2014. Here’s an update on the status at the end of the program. I’ve been moving over the past week and thus the delay in the update.
Over the past few weeks, I’ve been working on improving support for ARM. I added a jam target to automatically create a bootable MMC image and fix bugs in the haiku loader and also in the kernel. My original objective was to boot the kernel completely but I didn’t succeed in the attempt - it fails after sometime of booting into the kernel(an ASSERT fails in paging related routines). Few patches I’d submitted are yet to be merged(eg: #11131) to reach this failure. Currently, it seems that some of the latest changes prevent building again. #11144 tracks this issue. I’ve not investigated the issue yet so I am unsure what is going wrong.
I learnt many things by working on this project as well as had quite a few instances where I wasn’t sure if I was doing the right thing. Fortunately, several people were around to help out during those times - PulkoMandy, jessicah, kallisti5, revol, ithamar, Ingo and zhuowei. I can’t thank them enough since without them, I would be completely lost. Sadly, I probably won’t be able to continue work on this since I start work on my master thesis soon and working on the ARM port along with the thesis and coursework would be difficult. I’ll be able to judge better only in a few months time at least. Thanks to everyone who followed the weekly updates on the blog-o-sphere and supported the project! Till next time!
Here's a quick update for week 16. I didn't have internet access over the past few days due to a technical issue with my ISP and hence the delayed report.
TL;DR – The patch to prevent the kernel from overwriting the loader was merged last week. The next issues that need to be tackled are the KDL faulting when printing the backtrace and fixing an assertion that fails when initializing virtual memory.
TL;DR - It was decided that reserving space for the kernel instead of moving the entire memory map to a higher location. I’ve been working on that for most of last week and I think it would take a good part of this week to complete it since I seem to be running into many issues.
Here’s the update for week 14 of work on the Haiku ARM port. I was travelling for a good part of week 13 and thus couldn’t get much work done during the time.
TL;DR - The problems of kernel overwriting the loader code and the exceptions when setting up framebuffer have been temporarily solved. The framebuffer related code has been disabled for now and the entire memory map moved to a higher address(when FDT support is implemented, a lot of these problems probably won’t arise). Currently, a fault is raised when the kernel attempts to obtain the same lock twice, which drops to KDL.
Here’s a quick update for week #12.
TL;DR - The decompression process fails because the archive is present in a location that isn’t mapped by the MMU and subsequently allocated for the zlib output stream. No solutions have been discussed yet. It shouldn’t be long till the kernel is running hopefully :).
Here’s the update for week #11.
TL;DR - Haiku faults when trying to find the floppyboot archive present in stage2 loader. There seems to be a difference in few offsets/sizes, which causes different bytes to be read every time the loader tries to detect the archive.