Difference between revisions of "Winter 2011 Handout - RPM-Based ARM Kernels for Fedora ARM"
| Line 24: | Line 24: | ||
<!-- Describe the approach to the project -- method/procedure/tools etc --> | <!-- Describe the approach to the project -- method/procedure/tools etc --> | ||
| + | In PCs, when you turn on the machine, the system reads BIOS to locate the MBR which is the first 512 byte of hard disk. Then, the MBR says the location of GRUB and the GRUB program starts to load kernel. Finally, the kernel loads modules and init scripts to boot system up. In ARM system, because we do not have any BIOS or Hard disk, the process is different and it dose not have any GRUB. Instead, it has a Ramdisk or an image from file system that kernel loads that and boots from that. Now, we are going to make a package or RPM in case that we have several kernels installed in ARM and it should figure out to select the current kernel that it wants to load because it does not have any GRUB like PCs. So, this is the first approach for this project. Because we want to use initrd and modules which has a lot of features, we should build a kernel for a specific device which is impossible. Instead, we go to or load the generic kernel and the generic kernel can grab the module to know how to have access to hardware, but in order to do that, we should use a software such as Dracut to make the right module for a particular system. So, the Dracut is the second approach, and we should find a solution for working Dracut in ARM system. | ||
= Challenges = | = Challenges = | ||
<!-- Challenges that had to be met to complete the project --> | <!-- Challenges that had to be met to complete the project --> | ||
| + | One of the big challenges is compiling kernel and hardware modules in koji server. For each compile, it takes around two and half hours plus 40 minutes upload from remote connection which make situation hard for me to keep track of errors and focus on problems. Another challenge could be compiling kernel and setting parameters for config file for kernel. Binding this rpm with original kernel rpm can be also challenge since it needs to figure out all specific items in spec file and also pre and post script for installation. | ||
= Results = | = Results = | ||
Revision as of 16:04, 12 April 2011
Contents
Status
This page status is: DRAFT.
Title
RPM-Based ARM Kernels for Fedora ARM
Participants
Khosro Taraghi
Introduction
This project is related to making a RPM for kernels in Fedora ARM. Because of different architecture and hardware compared to PCs, the way that ARM loads kernels and other boot processes is different than PCs. We are going to make a RPM that loads kernels, modules, init, and other boot process in ARM system in standard way like PCs (Finding an alternative way for GRUB) and try to bind these packages together.
Approach
In PCs, when you turn on the machine, the system reads BIOS to locate the MBR which is the first 512 byte of hard disk. Then, the MBR says the location of GRUB and the GRUB program starts to load kernel. Finally, the kernel loads modules and init scripts to boot system up. In ARM system, because we do not have any BIOS or Hard disk, the process is different and it dose not have any GRUB. Instead, it has a Ramdisk or an image from file system that kernel loads that and boots from that. Now, we are going to make a package or RPM in case that we have several kernels installed in ARM and it should figure out to select the current kernel that it wants to load because it does not have any GRUB like PCs. So, this is the first approach for this project. Because we want to use initrd and modules which has a lot of features, we should build a kernel for a specific device which is impossible. Instead, we go to or load the generic kernel and the generic kernel can grab the module to know how to have access to hardware, but in order to do that, we should use a software such as Dracut to make the right module for a particular system. So, the Dracut is the second approach, and we should find a solution for working Dracut in ARM system.
Challenges
One of the big challenges is compiling kernel and hardware modules in koji server. For each compile, it takes around two and half hours plus 40 minutes upload from remote connection which make situation hard for me to keep track of errors and focus on problems. Another challenge could be compiling kernel and setting parameters for config file for kernel. Binding this rpm with original kernel rpm can be also challenge since it needs to figure out all specific items in spec file and also pre and post script for installation.
