Hello everyone,
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!
Hello everyone!
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.
Hello everyone!
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.
Hello everyone!
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.
Hey everyone!
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 :).
Hey everyone!
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.
Hey everyone!
Here’s the update for week #10. Sorry about the delay in posting there - I had some issues logging into the website over past few days.
TL;DR - MMU is enabled and now working!
Hey everyone!
The bootstrap-mmc target is now finally available! What this means is that you can follow all instructions in [1]
Hey everyone!
Just like week 6, this is another short update.
I’ve been working on creating a bootstrap-mmc target for the build system. The current issues I’m facing are
- Downloading MLO and u-boot fails and thus build fails since jam doesn’t know how to create those targets otherwise. I managed to fix this but apparently, the fix breaks the current build system so I need to modify the fix such that it doesn’t break the build system.
- Copying the bootstrap image as the second partition of the MMC image. I planned to use dd since it works fine and probably works fine on Linux and BSDs but dd requires a size to be specified, which is slightly tricky to compute in jam. The obvious solution of using cat doesn’t seem to work - the resultant size of MMC is much higher than expected.
I hope to add the bootstrap-mmc target for jam within this week which would make it much easier for anyone to build the image.
Hey everyone!
Here’s an update on week 6(a relatively short one so no TL;DR :) ).
I managed to fix the bootable SD card image generation script that I created last week to use mtools and thus eliminate the need for losetup and root permissions. The script is available in a Github[1] repository
Meanwhile, I’ve also been working on adding a bootstrap-mmc target to Jam. Right now, the target generates the haiku_loader_nbsd.ub successfully but fails because it doesn’t know how to generate MLO and u-boot. I have not figured out why it doesn’t know how to make targets MLO and u-boot. Hopefully, I’ll fix that up in a few days.
[1] https://github.com/arvindsraj/haiku-sdcard-image-generator
