soc:2010:multiboot:start [Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Multiboot Compliance ======

Student: Feiran Zheng\\ 
Mentor: Erik van der Kouwe\\
SVN branch name: [[http://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Fbranches%2Fsrc.r7906.fam%2F|src.r7906.fam]]\\

===== Contents =====

===== Abstract =====

This page is for GSoC-2010 project "Making MINIX Multiboot Compliant". It it to be updated during the following several months for tracking the work progress and also for documentation.

===== Project Idea =====

Currently, MINIX 3 has its own boot loader (Boot Monitor, BM for abbreviation) , but it is quite old and has some serious limitations. We are going to change the booting structure to use a modern boot loader such as GRUB 2 (without chainloading).

===== A Comparison between Boot Monitor and GRUB =====

A document comparing current boot monitor and GRUB is made, trying to specify the main differences, and giving a brief introduction to how to make the image compatible in the last section. Follow the link below to check details.

[[.:frombootmonitortogrub|FromBootMonitorToGRUB]]

===== Boot Parameters when Using GRUB =====

The Multiboot support of MINIX automatically determines all the necessary parameters such as ''rootdev'', ''memory'' and others those are listed with ''sysenv''. An exception is ''image'', since from the boot information that GRUB provides, the loaded image file name can't be retrieved. As a result GRUB users should better specify the value of ''image='' with GRUB command line, if they are booting an image file other than ''/boot/image_latest''. If not, this file name is given by default. On the other hand, any parameter value can also be overridden in the same way.

To set boot parameter values in GRUB, simply append parameters to the ''multiboot'' command line when booting MINIX. For example to designate the value of ''image'' with ''/boot/image_latest'', and value of ''rootdev'' with 896, modify the ''multiboot'' command as follows:

''multiboot /boot/image_latest image=/boot/image_latest rootdev=896''

(Refer to [[.:howto|Multiboot Howto]] for more context.)

No parameter is required for a normal boot of MINIX, but it is sometimes helpful to specify values such as cttyline and rootdev for test purpose. So only do this when you need to.

===== Status =====

Basic multiboot support has been merged into the MINIX trunk. When using MINIX trunk (since r7906), you can boot newly created images in /boot/image using a multi-boot compliant bootloader that supports the MINIX 3 filesystem and MINIX-style subpartitions. To boot the newest image, specify /boot/image_latest. This file is a hard link to the newest image and is updated automatically when a new image is installed. 

There currently are no multi-boot compliant bootloaders that support the MINIX 3 filesystem and MINIX-style subpartitions. We are working on getting a patch in GRUB 2. The patch can already be used if you compile GRUB yourself, and is found here: [[http://www.cs.vu.nl/~vdkouwe/minix/multiboot/grub_minix.patch|Minix 3 subpartition/filesystem patch]].

Here's a brief introduction to the steps to compile and configure GRUB to test the Multiboot kernel: [[.:howto|Multiboot Howto]]

===== Progress reports =====

==== Preparing and Applying Period (2010-3-1 to 2010-4-15) ====
Since a month earlier before the application period of GSoC 2010 began, I started preparing for applying GSoC. By reading the book, following posts in group list and testing MINIX in VM I learned much about it and finally completed the application successfully on 26th April. 

==== Community Bonding Period (2010-4-26 to 2010-5-24) ====
Period for students to get familiar with the project and organization.
After several times of discussion with Erik, the basic ideas have become clearer. The comparison between BM and GRUB and a brief to how to carry out the change have been documented as the link above points. A branch in SVN repository has been set up for the project, a development environment with virtual machine softwares under Linux is ready too.

==== Week #1 ====
The mid term goals are roughly two:
  *The multi-boot implementation must support passing boot configuration parameters to MINIX as it does with the boot monitor;
  *The primary focus is on GRUB 2, which must be capable of booting a default MINIX installation (for now that probably means sub-partitioned MFS) without chainloading;

Consequently, we have four things to do to reach that, they are orderly as following:
  - setup GDT
  - setup stack
  - save parameters to a global variable, so that latter kernel may read it
  - extract and initialize program segments in image_mb

The first two of these have been done in this week. The third one is on his way: about half of the parameters which MINIX needs are now available, the rest are to be done.

Besides the MINIX SVN repository branch, I've created a //github// page at 
[[http://github.com/famousz/multiboot/|GithubPage]]
to track developing, building and testing configurations and scripts as well as modified source code. Changes are commited regularly there.

==== Week #2 ====
This week I continue on previous work with boot parameters parsing. Now All the typical parameters in 'sysenv' are present in a buffer, which can be later passed to kernel. The var 'bus', 'video' and 'chrome' are hard coded to 'at', 'ega' and 'color', as other options of them are very unlikely possible or valid. 

It seems we can't get image filename to set 'image=' from multiboot specification, as a result, it's a dummy value now, unless assigned by grub cmdline parameter (e.g. grub>multiboot /boot/image_mb image=/boot/image_mb ).

==== Week #3 ====
In this week all four subtasks are done and the system can now be booted by GRUB Multiboot. The remaining problem concerns system shutdown. Reboot/poweroff command cannot perform correctly for the non-presence of Boot Monitor, so these functionalities have to be implemented in kernel code, which involves returning to real mode and do some BIOS calls.

==== Week #4,#5 ====
When testing the compiled kernel, a few problems were encountered, such as cannot detecting the rootdev automatically and not parsing the parameters denoted with GRUB command line correctly. By now these two bugs have been tested and fixed, but there is another remaining problem with kvm on QEMU: it doesn't boot normally, but resets the VM very quickly instead. My following work will be solving this and write a detailed guide on how to setup a VM to compile and test the Multiboot compliant MINIX kernel.

==== Week #6 ====
Debug on a new machine that supports KVM, a bug that prevents KVM to Multiboot the kernel correctly is fixed, so we can boot up KVM now.

==== Week #7,#8 ====
There were several library functions such as strlen, strncmp, strcpy etc. that didn't work with Multiboot pre_init code, and those were all re-implemented locally. Lately I debugged the library functions and found the reason, it was where they use registers such as EDI that address in ES segment by default, the library makes assumption that ES addresses the same segment as DS, but our ES here are set to 4GB plain segment. However the difference will not result in any exception so the library function call will return, after R/W unexpected memory. 

To make the library functions work, we set ES equal to DS in asm before entering pre_init, and restore it after pre_init returns. This is OK because only phys_copy needs plain memory access and this function itself takes care of ES (saving, loading and restoring).

The library function itoa uses two global variables that are in BSS, which is not initialized yet here, so we mustn't call this. As a result mb_itoa comes up.

Formerly, poweroff was a functionality of boot monitor, which returns to real mode and do BIOS call to shutdown the power. Boot monitor is no longer available for our Multiboot kernel, so the poweroff function is now implemented in kernel. The procedure is similar, except copying a small piece of code into below 1MB which will be jumped to after switch back to real mode and executed for BIOS calls. It works perfectly in QEMU without KVM, but in some cases can't close the VM when KVM enabled, which needs further debugging.

A patch for GRUB to support Minix subpartition and MFSv3 was sent to GRUB mailing list recently, although no response yet. A wiki page that describes how to test Multiboot feature of MINIX is being prepared too.

==== Week #9, #10 ====
Continue improving the GRUB patch as suggested by its developer. Was asked to send a copyright assignment for making contribution to the GRUB file system modules. When I completed the request they have acquired, a document to sign was emailed to me, which I'm supposed to fill, before the contribution is accepted.

The previous branch for Multiboot was merged into trunk earlier, so there's a new branch now. Most of the new features are in trunk and ready to use at the moment. Erik and I have made some wiki pages (see above) as a guide to install and test Multiboot of MINIX, including how to compile a patched GRUB 2 to read MINIX subpartitions. If the patch is accepted by GRUB and released in a future version, it'll be easier to do this.

The command ''reboot'' was mapped to poweroff earlier, but now it's changed to soft reset of CPU. ''Shutdown'' performs a returning to Boot Monitor if booted from it, but for Multiboot it's not possible. So it's mapped to poweroff. Similarly, the parameter of reboot code for ''reboot'' command is ignored unless when the parameter contains substring "boot", in which case it's mapped to soft reset (the same strategy with reboot).
User Tools

Site Tools

Page Tools
