Booting kernel (FIT image) with no rootfs
An embedded Linux device I am working with has the following kernel parameter:
root=/dev/ram0
Additionally, the kernel image is bundled together with an initrd and device tree to make a flattened image tree, or FIT image.
When fully booted the device does not have persistent storage. That is, anything written to the file system is completely volatile. Considering the root= parameter passed to the kernel, this is not surprising.
My questions is: How does this work?
I do know that Uboot copies the kernel into ram and executes it with a
bootmcommand, but where do the filesystem files come from? Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passingroot=/dev/ram0sufficient for the kernel to know where its file system is?Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
linux kernel boot ram initrd
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
bumped to the homepage by Community♦ 54 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
An embedded Linux device I am working with has the following kernel parameter:
root=/dev/ram0
Additionally, the kernel image is bundled together with an initrd and device tree to make a flattened image tree, or FIT image.
When fully booted the device does not have persistent storage. That is, anything written to the file system is completely volatile. Considering the root= parameter passed to the kernel, this is not surprising.
My questions is: How does this work?
I do know that Uboot copies the kernel into ram and executes it with a
bootmcommand, but where do the filesystem files come from? Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passingroot=/dev/ram0sufficient for the kernel to know where its file system is?Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
linux kernel boot ram initrd
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
bumped to the homepage by Community♦ 54 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
An embedded Linux device I am working with has the following kernel parameter:
root=/dev/ram0
Additionally, the kernel image is bundled together with an initrd and device tree to make a flattened image tree, or FIT image.
When fully booted the device does not have persistent storage. That is, anything written to the file system is completely volatile. Considering the root= parameter passed to the kernel, this is not surprising.
My questions is: How does this work?
I do know that Uboot copies the kernel into ram and executes it with a
bootmcommand, but where do the filesystem files come from? Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passingroot=/dev/ram0sufficient for the kernel to know where its file system is?Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
linux kernel boot ram initrd
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
An embedded Linux device I am working with has the following kernel parameter:
root=/dev/ram0
Additionally, the kernel image is bundled together with an initrd and device tree to make a flattened image tree, or FIT image.
When fully booted the device does not have persistent storage. That is, anything written to the file system is completely volatile. Considering the root= parameter passed to the kernel, this is not surprising.
My questions is: How does this work?
I do know that Uboot copies the kernel into ram and executes it with a
bootmcommand, but where do the filesystem files come from? Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passingroot=/dev/ram0sufficient for the kernel to know where its file system is?Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
linux kernel boot ram initrd
linux kernel boot ram initrd
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
asked Jun 28 '16 at 17:49
sherrellbcsherrellbc
85331527
85331527
bumped to the homepage by Community♦ 54 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 54 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I do know that Uboot copies the kernel into ram and executes it with a bootm command, but where do the filesystem files come from?
Before you can boot your fitImage you have to load it into RAM. After this you can start it with bootm. Inside the fit image you can define the Load Address and Entry Point for the kernel for example.
Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passing root=/dev/ram0 sufficient for the kernel to know where its file system is?
It depends on your system what the definition of filesystem is. There are a few systems running completely from a RAMDISK and just storing configuration into any kind of NVRAM or Flash.
Other systems use the RAMDisk to check where to find the root filesystem. For example to scan USB-Bus, SATA or SD-Cards. When the root filesystem is mounted the boot process continuous with this partition. Due to the fact that init needs to run from PID 1. Some tricks are needed.
Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
No the fitImage is parsed by u-boot. How the u-boot passes the addresses where the DTB and RAMDISK is located at depends on the used Platform AFAIK.
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
When changes to the filesystems are needed on a regular basis you should consider to use something more flexible. But this depends on the hardware you are using. SD-Card, NAND, NOR or spinning disks.
answered Jul 26 '16 at 5:52
graugansgraugans
11
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f292656%2fbooting-kernel-fit-image-with-no-rootfs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I do know that Uboot copies the kernel into ram and executes it with a bootm command, but where do the filesystem files come from?
Before you can boot your fitImage you have to load it into RAM. After this you can start it with bootm. Inside the fit image you can define the Load Address and Entry Point for the kernel for example.
Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passing root=/dev/ram0 sufficient for the kernel to know where its file system is?
It depends on your system what the definition of filesystem is. There are a few systems running completely from a RAMDISK and just storing configuration into any kind of NVRAM or Flash.
Other systems use the RAMDisk to check where to find the root filesystem. For example to scan USB-Bus, SATA or SD-Cards. When the root filesystem is mounted the boot process continuous with this partition. Due to the fact that init needs to run from PID 1. Some tricks are needed.
Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
No the fitImage is parsed by u-boot. How the u-boot passes the addresses where the DTB and RAMDISK is located at depends on the used Platform AFAIK.
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
When changes to the filesystems are needed on a regular basis you should consider to use something more flexible. But this depends on the hardware you are using. SD-Card, NAND, NOR or spinning disks.
answered Jul 26 '16 at 5:52
graugansgraugans
11
add a comment |
I do know that Uboot copies the kernel into ram and executes it with a bootm command, but where do the filesystem files come from?
Before you can boot your fitImage you have to load it into RAM. After this you can start it with bootm. Inside the fit image you can define the Load Address and Entry Point for the kernel for example.
Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passing root=/dev/ram0 sufficient for the kernel to know where its file system is?
It depends on your system what the definition of filesystem is. There are a few systems running completely from a RAMDISK and just storing configuration into any kind of NVRAM or Flash.
Other systems use the RAMDisk to check where to find the root filesystem. For example to scan USB-Bus, SATA or SD-Cards. When the root filesystem is mounted the boot process continuous with this partition. Due to the fact that init needs to run from PID 1. Some tricks are needed.
Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
No the fitImage is parsed by u-boot. How the u-boot passes the addresses where the DTB and RAMDISK is located at depends on the used Platform AFAIK.
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
When changes to the filesystems are needed on a regular basis you should consider to use something more flexible. But this depends on the hardware you are using. SD-Card, NAND, NOR or spinning disks.
answered Jul 26 '16 at 5:52
graugansgraugans
11
add a comment |
I do know that Uboot copies the kernel into ram and executes it with a bootm command, but where do the filesystem files come from?
Before you can boot your fitImage you have to load it into RAM. After this you can start it with bootm. Inside the fit image you can define the Load Address and Entry Point for the kernel for example.
Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passing root=/dev/ram0 sufficient for the kernel to know where its file system is?
It depends on your system what the definition of filesystem is. There are a few systems running completely from a RAMDISK and just storing configuration into any kind of NVRAM or Flash.
Other systems use the RAMDisk to check where to find the root filesystem. For example to scan USB-Bus, SATA or SD-Cards. When the root filesystem is mounted the boot process continuous with this partition. Due to the fact that init needs to run from PID 1. Some tricks are needed.
Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
No the fitImage is parsed by u-boot. How the u-boot passes the addresses where the DTB and RAMDISK is located at depends on the used Platform AFAIK.
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
When changes to the filesystems are needed on a regular basis you should consider to use something more flexible. But this depends on the hardware you are using. SD-Card, NAND, NOR or spinning disks.
answered Jul 26 '16 at 5:52
graugansgraugans
11
I do know that Uboot copies the kernel into ram and executes it with a bootm command, but where do the filesystem files come from?
Before you can boot your fitImage you have to load it into RAM. After this you can start it with bootm. Inside the fit image you can define the Load Address and Entry Point for the kernel for example.
Are they contained within the initrd? My understanding of an initrd is that it is a temporary construct. If so, it would be an offset into FIT image blob. So, how is just passing root=/dev/ram0 sufficient for the kernel to know where its file system is?
It depends on your system what the definition of filesystem is. There are a few systems running completely from a RAMDISK and just storing configuration into any kind of NVRAM or Flash.
Other systems use the RAMDisk to check where to find the root filesystem. For example to scan USB-Bus, SATA or SD-Cards. When the root filesystem is mounted the boot process continuous with this partition. Due to the fact that init needs to run from PID 1. Some tricks are needed.
Does the kernel perform introspection and read the FIT image's header to determine placement of constituent components?
No the fitImage is parsed by u-boot. How the u-boot passes the addresses where the DTB and RAMDISK is located at depends on the used Platform AFAIK.
How are file system changes supported inside a FIT image considering it will be packed together with both the kernel and device tree blob?
When changes to the filesystems are needed on a regular basis you should consider to use something more flexible. But this depends on the hardware you are using. SD-Card, NAND, NOR or spinning disks.
answered Jul 26 '16 at 5:52
graugansgraugans
11
answered Jul 26 '16 at 5:52
graugansgraugans
11
answered Jul 26 '16 at 5:52
graugansgraugans
11
answered Jul 26 '16 at 5:52
graugansgraugans
11
11
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f292656%2fbooting-kernel-fit-image-with-no-rootfs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
