Difference between revisions of "RPM-based Kernels for Fedora ARM"
| Line 23: | Line 23: | ||
== Project Details == | == Project Details == | ||
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 | 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. | + | 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. | 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. | ||
<!-- Provides more depth than the Project Description. This is the place for technical discussions, project specs, or other details. If this gets very long, you might consider breaking this part into multiple pages and linking to them. --> | <!-- Provides more depth than the Project Description. This is the place for technical discussions, project specs, or other details. If this gets very long, you might consider breaking this part into multiple pages and linking to them. --> | ||
| Line 37: | Line 37: | ||
<!-- Note: each contributor is expected to have unique goals. These goals may be ''related'' to other students' work, but must be ''distinct'' and ''attainable'' regardless of the state of the other students' work. For example, under the umbrella of one project title, one student may work on packaging a piece of software and another may work on documentation, or one may work on solving one bug and another on solving another bug, but two students must not work on the same bug or depend on the other students' work in order to be able to complete their own project. --> | <!-- Note: each contributor is expected to have unique goals. These goals may be ''related'' to other students' work, but must be ''distinct'' and ''attainable'' regardless of the state of the other students' work. For example, under the umbrella of one project title, one student may work on packaging a piece of software and another may work on documentation, or one may work on solving one bug and another on solving another bug, but two students must not work on the same bug or depend on the other students' work in order to be able to complete their own project. --> | ||
* 0.1 | * 0.1 | ||
| + | Find an alternative way for GRUB in ARM system | ||
* 0.2 | * 0.2 | ||
| + | Find a solution for Dracut to work in ARM system | ||
* 0.3 | * 0.3 | ||
| + | Bind together as a package, Documentation, and Presentation. | ||
== Communication == | == Communication == | ||
Revision as of 22:39, 30 January 2011
Contents
RPM-based Kernels for Fedora ARM
Project Description
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 and try to bind these packages together.
Project Leader(s)
Chris Tyler, Fedora ARM List
Project Contributor(s)
Project Details
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.
Project Plan
Tracking mechanism (bugzilla, trac, github, ...):
Key contacts:
Goals for each release and plans for reaching those goals:
- 0.1
Find an alternative way for GRUB in ARM system
- 0.2
Find a solution for Dracut to work in ARM system
- 0.3
Bind together as a package, Documentation, and Presentation.
