list of 2.6-related migration issues for embedded programmers?

list of 2.6-related migration issues for embedded programmers?

[Robert P. J. Day]

   on the topic of lists of things, is there a list somewhere of the
potentially important 2.6-related issues someone should at least
understand before migrating from 2.4 to 2.6?  i don't mean just
improvements in the kernel from 2.4 to 2.6; i mean significantly new
features that would require a rethinking and possible redesign of the
build process.  as examples off the top of my head:

   - replace devfs with udev:  currently, even with my current 8xx 2.6
build, i'm sticking with devfs until i'm confident i understand enough
to move up.

   - initramfs:  currently, i'm still using a zImage.initrd-based
image, and all i know about initramfs is that it's checked for at boot
time.  should i care about it?  at some point, probably, i'm sure.

   - redesign of modules and device drivers to be 2.6-compatible,
that's a biggie.  and the fact that the CVS busybox tree just recently
had 2.6 support added to its modules-related commands.

   - totally redesigned kernel config menus

   at the moment, i'm going through the 5-part series on migrating to
2.6 starting at http://linuxdevices.com/articles/AT3855888078.html.
some of it's useful, some of it's kind of fluffy.  but it would be
nice to have a list of that type aimed primarily at embedded
developers.

rday

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

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

[Linh Dang]

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

>
>
> - replace devfs with udev:  currently, even with my current 8xx 2.6
> build, i'm sticking with devfs until i'm confident i understand
> enough to move up.

It depends on your need. For our project, we don't use neither. Our
init script read sysfs and do all the mknod-ings at boot time. it's
just 2 for-loops of 3-lines each. But ofcourse, we have no hot-plug
devices nor loadable modules.


>
> - initramfs:  currently, i'm still using a zImage.initrd-based
> image, and all i know about initramfs is that it's checked for at
> boot time.  should i care about it?  at some point, probably, i'm
> sure.

initramfs is convenient. you don't need root access nor special tools
to create the root-fs. it very easy when you want to
version-controlled you root-fs.


my $0.02

--
L.D.

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

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

[Robert P. J. Day]

On Mon, 19 Jul 2004, Linh Dang wrote:

> On 19 Jul 2004, rpjday@mindspring.com wrote:

>> - initramfs:  currently, i'm still using a zImage.initrd-based
>> image, and all i know about initramfs is that it's checked for at
>> boot time.  should i care about it?  at some point, probably, i'm
>> sure.
>
> initramfs is convenient. you don't need root access nor special tools
> to create the root-fs. it very easy when you want to
> version-controlled you root-fs.

ah, that would be convenient since, as it is, i'm using a hacked
version of "genext2fs" that allows me to create the initial root fs as
a regular user.  i *definitely* have to look into initramfs, then.

rday

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

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

[Linh Dang]

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

> On Mon, 19 Jul 2004, Linh Dang wrote:
>
>> On 19 Jul 2004, rpjday@mindspring.com wrote:
>
>>> - initramfs:  currently, i'm still using a zImage.initrd-based
>>> image, and all i know about initramfs is that it's checked for at
>>> boot time.  should i care about it?  at some point, probably, i'm
>>> sure.
>>
>> initramfs is convenient. you don't need root access nor special
>> tools to create the root-fs. it very easy when you want to
>> version-controlled you root-fs.
>
> ah, that would be convenient since, as it is, i'm using a hacked
> version of "genext2fs" that allows me to create the initial root fs
> as a regular user.  i *definitely* have to look into initramfs,
> then.

Don't use the .initramfs section option (the one that's linked with
with vmlinux.) Build your ramdisk.image.gz as a compressed cpio
archive. I.e. zvmlinux.initrd's .ramdisk section contains a compressed
cpio archive instead of an compressed ext2 image.

--
L.D.

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

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

[Robert P. J. Day]

On Mon, 19 Jul 2004, Linh Dang wrote:

> Don't use the .initramfs section option (the one that's linked with
> with vmlinux.) Build your ramdisk.image.gz as a compressed cpio
> archive. I.e. zvmlinux.initrd's .ramdisk section contains a compressed
> cpio archive instead of an compressed ext2 image.

that's all it takes?  that sounds just too easy.

rday

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

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

[Robert P. J. Day]

On Mon, 19 Jul 2004, Linh Dang wrote:

> Don't use the .initramfs section option (the one that's linked with
> with vmlinux.) Build your ramdisk.image.gz as a compressed cpio
> archive. I.e. zvmlinux.initrd's .ramdisk section contains a compressed
> cpio archive instead of an compressed ext2 image.

so, just to clarify, i'm looking at arch/ppc/boot/simple/Makefile, the
excerpt:

$(obj)/zvmlinux.initrd: $(OBJS) $(LIBS) $(srctree)/$(boot)/ld.script \
                 $(images)/vmlinux.gz $(obj)/dummy.o
         $(OBJCOPY) $(OBJCOPY_ARGS) \
-->             --add-section=.ramdisk=$(images)/ramdisk.image.gz \
 		--set-section-flags=.ramdisk=contents,alloc,load,readonly,data \

and all i need to change is "ramdisk.image.gz" to, say, my "newc"
format gzipped cpio archive, "initramfs.cpio.gz", and the early kernel
code should recognize it as such automatically?

i'll give that a shot later.

rday

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

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

[Linh Dang]

On 19 Jul 2004, rpjday@mindspring.com wrote:
[...]
>
> and all i need to change is "ramdisk.image.gz" to, say, my "newc"
> format gzipped cpio archive, "initramfs.cpio.gz", and the early
> kernel code should recognize it as such automatically?
>
> i'll give that a shot later.
>
> rday

look at populate_rootfs(), it's that simple. Our local kernel tree has
the following in the boot/simple/Makefile:

ZRDIMAGE := $(images)/ramdisk.image.gz
ROOTDIR := $(srctree)/............/path/to/dir/containing/root-fs

$(ZRDIMAGE) :  $(OUR_LOCAL_RULES_FOR_BUSYBOX) FORCE
        (cd $(ROOTDIR) &&  find | grep -v '~$$' | cpio -o -Hnewc ) | \
        gzip -9 -c > $@

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

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

[Wolfgang Denk]

In message <Pine.LNX.4.60.0407191350320.23725@dell.enoriver.com> you wrote:
>
> > initramfs is convenient. you don't need root access nor special tools
> > to create the root-fs. it very easy when you want to
> > version-controlled you root-fs.
>
> ah, that would be convenient since, as it is, i'm using a hacked
> version of "genext2fs" that allows me to create the initial root fs as
> a regular user.  i *definitely* have to look into initramfs, then.

What do you mean with "hacked"? Standard  "genext2fs"  will  do  this
just fine.

And as usual, there is two sides to initramfs. It may  be  convenient
for some cases, where you can use the very same root filesystem image
bundled  with the kernel image, but exactly thsi convenience may hurt
you in other cases where it's much better  when  you  have  separated
images which can be updated independently of each other.

Speaking for myself: I don't see advantages in it. None.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I used to be indecisive, now I'm not sure.

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

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

[Robert P. J. Day]

On Mon, 19 Jul 2004, Wolfgang Denk wrote:

> In message <Pine.LNX.4.60.0407191350320.23725@dell.enoriver.com> you wrote:
>>
>>> initramfs is convenient. you don't need root access nor special tools
>>> to create the root-fs. it very easy when you want to
>>> version-controlled you root-fs.
>>
>> ah, that would be convenient since, as it is, i'm using a hacked
>> version of "genext2fs" that allows me to create the initial root fs as
>> a regular user.  i *definitely* have to look into initramfs, then.
>
> What do you mean with "hacked"? Standard  "genext2fs"  will  do  this
> just fine.

sadly for me, the version floating around doesn't build FIFOs (even
though the command-line options suggest it does).  and i need FIFOs to
support minit.  so i merged a couple different versions to get one
that handles the extended device file format (erik andersen's??), and
a small patch to handle FIFOs.

> And as usual, there is two sides to initramfs. It may  be  convenient
> for some cases, where you can use the very same root filesystem image
> bundled  with the kernel image, but exactly thsi convenience may hurt
> you in other cases where it's much better  when  you  have  separated
> images which can be updated independently of each other.
>
> Speaking for myself: I don't see advantages in it. None.

i most likely wouldn't use it for the final build, but it would still
be more efficient for testing, rather than reflashing the root
filesystem on the unit every time.  once the image is finalized, then
i can flash the kernel and rootFS separately.

rday

p.s.  of course, this assumes GNU cpio can handle FIFOs.  oops, better
check that.

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

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

[Wolfgang Denk]

In message <Pine.LNX.4.60.0407191731390.24783@dell.enoriver.com> you wrote:
>
> sadly for me, the version floating around doesn't build FIFOs (even
> though the command-line options suggest it does).  and i need FIFOs to
> support minit.  so i merged a couple different versions to get one
> that handles the extended device file format (erik andersen's??), and
> a small patch to handle FIFOs.

I thought Erik Anderse's version _is_ the standard version these days ;-)

And I thought you were using the ELDK?

> i most likely wouldn't use it for the final build, but it would still
> be more efficient for testing, rather than reflashing the root
> filesystem on the unit every time.  once the image is finalized, then
> i can flash the kernel and rootFS separately.

I can't follow. Why would you flash the  root  filesystem  if  you're
still  testing  it? Just TFTP the test image and use it from RAM (the
kernel may be stored in flash if you like).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Quotation, n. The act of repeating erroneously the words of  another.
The  words  erroneously  repeated.
                            - Ambrose Bierce _The Devil's Dictionary_

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

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

[Robert P. J. Day]

On Tue, 20 Jul 2004, Wolfgang Denk wrote:

> In message <Pine.LNX.4.60.0407191731390.24783@dell.enoriver.com> you wrote:
>>
>> sadly for me, the version floating around doesn't build FIFOs (even
>> though the command-line options suggest it does).  and i need FIFOs to
>> support minit.  so i merged a couple different versions to get one
>> that handles the extended device file format (erik andersen's??), and
>> a small patch to handle FIFOs.
>
> I thought Erik Anderse's version _is_ the standard version these days ;-)

it is, except as i mentioned, it doesn't support FIFOs, although it
does handle the extended device file format that i needed.  i got
another version that didn't support the extended file format, but
handled FIFOs.  quick merge, and i had what i wanted.

> And I thought you were using the ELDK?

i am.  not sure what that has to do with genext2fs.  what's a big deal
for me is to make sure the entire build and test process can be done
without any access to the root account on the development system.

>> i most likely wouldn't use it for the final build, but it would still
>> be more efficient for testing, rather than reflashing the root
>> filesystem on the unit every time.  once the image is finalized, then
>> i can flash the kernel and rootFS separately.
>
> I can't follow. Why would you flash the  root  filesystem  if  you're
> still  testing  it? Just TFTP the test image and use it from RAM (the
> kernel may be stored in flash if you like).

but the whole idea is that using genext2fs required me to make a
couple small changes to allow non-root users to do the entire process.
IIRC, the ability to mount and umount.  initramfs looks like an easier
way to just let regular users do all this.  and when we have the final
image, then burn *that* to flash.

sorry, i didn't mean to drag this out so much.  i just see initramfs
as a cheap and easy way to let non-root users build and test.  and if
i can reduce my dependency on tools additional (i.e., genext2fs), so
much the better.

rday

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

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

[Linh Dang]

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

> And as usual, there is two sides to initramfs. It may be convenient
> for some cases, where you can use the very same root filesystem
> image bundled with the kernel image, but exactly thsi convenience
> may hurt you in other cases where it's much better when you have
> separated images which can be updated independently of each other.

Maybe I missed some thing but:

        - I'm using initramfs in my current project (2.6.7)
        - I failed to see what in initramfs mechanism would prevent
          one from having "separated images which can be updated
          independently of each other."


Regards
--
L.D.


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

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

[Wolfgang Denk]

In message <wn5zn5v8nl8.fsf@linhd-2.ca.nortel.com> 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/

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

[Linh Dang]

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

> In message <wn5zn5v8nl8.fsf@linhd-2.ca.nortel.com> 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

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/

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

[Robert P. J. Day]

On Tue, 20 Jul 2004, Linh Dang wrote:

>
> On 20 Jul 2004, wd@denx.de wrote:
>
>> In message <wn5zn5v8nl8.fsf@linhd-2.ca.nortel.com> 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
>
> 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/

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

[Linh Dang]

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

> On Tue, 20 Jul 2004, Linh Dang wrote:
>
>>
>> On 20 Jul 2004, wd@denx.de wrote:
>>
>>> In message <wn5zn5v8nl8.fsf@linhd-2.ca.nortel.com> 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
>>
>> 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/

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

[Mark Chambers]

> >> - 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/

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

[Wolfgang Denk]

In message <wn5vfgi9arw.fsf@linhd-2.ca.nortel.com> you wrote:
>
> 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.

How do I populate a  initramfs  with  custom  device  nodes?  Without
having root permission, I mean.

And how can I tell a Linux kernel where to find  the  initramfs  data
when they are not linked together?

> 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.

That's OK. Other projects may have different requirements, though.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
You cannot propel yourself forward by patting yourself on the back.

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

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

[Linh Dang]

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

> In message <wn5vfgi9arw.fsf@linhd-2.ca.nortel.com> you wrote:
>>
>> 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.
>
> How do I populate a initramfs with custom device nodes?  Without
> having root permission, I mean.

You have a point here, I guess with initramfs you have to:

 - use devfs (which was deprecated in 2.6)
 - use udev
 - grok-sysfs-yourself (which is pretty easy)

>
> And how can I tell a Linux kernel where to find the initramfs data
> when they are not linked together?

Well, the same way as with the good old-initrd. the initramfs root-fs
IS an INITRD in compressed-cpio format (instead of fs format such as
ext2).


me think I'm still missing something about initrd.


Regards

--
L.D.

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