Re: list of 2.6-related migration issues for embedded programmers?

In message [off-list ref] you wrote:

        - I failed to see what in initramfs mechanism would prevent
          one from having "separated images which can be updated
          independently of each other."

initramfs gets linked with the kernel into one image, similar to what
you got when building a zImage.initrd image.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On 20 Jul 2004, wd@denx.de wrote:

In message [off-list ref] you wrote:

quoted

- I failed to see what in initramfs mechanism would prevent
one from having "separated images which can be updated
independently of each other."

initramfs gets linked with the kernel into one image, similar to

But you don't have to. What ever you can do with the good-old initrd
image you can do with the new initramfs (really cpio archive)
image. The main difference is the creation: genext2fs vs cpio.

I just happen to use zImage.initrd (where ramdisk.image.gz is a cpio
archive) in our project because it's the most appropriate for our
situation.

Regards

--
L.D.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Tue, 20 Jul 2004, Linh Dang wrote:

On 20 Jul 2004, wd@denx.de wrote:

quoted

In message [off-list ref] you wrote:

quoted

- I failed to see what in initramfs mechanism would prevent
one from having "separated images which can be updated
independently of each other."

initramfs gets linked with the kernel into one image, similar to

But you don't have to. What ever you can do with the good-old initrd
image you can do with the new initramfs (really cpio archive)
image. The main difference is the creation: genext2fs vs cpio.

I just happen to use zImage.initrd (where ramdisk.image.gz is a cpio
archive) in our project because it's the most appropriate for our
situation.

i have to agree with wolfgang here -- how would you create and use an
initramfs image separately from the kernel image?  the only
possibility i can see based on my perusal is to incorporate the
initramfs into the zImage.initrd.

rday

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

quoted

quoted

- I failed to see what in initramfs mechanism would prevent
one from having "separated images which can be updated
independently of each other."

initramfs gets linked with the kernel into one image, similar to

But you don't have to. What ever you can do with the good-old initrd
image you can do with the new initramfs (really cpio archive)
image. The main difference is the creation: genext2fs vs cpio.

I just happen to use zImage.initrd (where ramdisk.image.gz is a cpio
archive) in our project because it's the most appropriate for our
situation.

Regards

--
L.D.

So you can have a separate uboot image (from mkimage) that you can update
separately and it will get passed to the kernel on boot?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On 20 Jul 2004, rpjday@mindspring.com wrote:

On Tue, 20 Jul 2004, Linh Dang wrote:

quoted

On 20 Jul 2004, wd@denx.de wrote:

quoted

In message [off-list ref] you wrote:

quoted

- I failed to see what in initramfs mechanism would prevent
one from having "separated images which can be updated
independently of each other."

initramfs gets linked with the kernel into one image, similar to

But you don't have to. What ever you can do with the good-old
initrd image you can do with the new initramfs (really cpio
archive) image. The main difference is the creation: genext2fs vs
cpio.

I just happen to use zImage.initrd (where ramdisk.image.gz is a
cpio archive) in our project because it's the most appropriate for
our situation.

i have to agree with wolfgang here -- how would you create and use
an initramfs image separately from the kernel image?  the only
possibility i can see based on my perusal is to incorporate the
initramfs into the zImage.initrd.

Hmm, I will have to try it (when I have time). From reading the kernel
code, the kernel itself doesn't care where the initramfs came from
(whether it's in the .ramdisk section or it's passed from the
bootloader). The kernel decompresses the data at initrd_start and look
for cpio magic. if that failed, it'll try to use the data as a
compress fs image.

I've never tried uboot because we have our own custom bootloader here
(for our own proprietary boards) so I have no idea about uboot's
features/limitations.

Regards

--
L.D.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/