Difference between revisions of "RPM-based Kernels for Fedora ARM"
| Line 24: | Line 24: | ||
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. IN ARM system, because we do not have any BIOS or Hard disk, 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. | + | 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 us. |
<!-- 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. --> | ||
Revision as of 22:20, 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 us.
Project Plan
Tracking mechanism (bugzilla, trac, github, ...):
Key contacts:
Goals for each release and plans for reaching those goals:
- 0.1
- 0.2
- 0.3
