Actions
Forum Thread Details
  • State Not Answered
  • Replies 8 replies
  • Subscribers 371 subscribers
  • Views 3156 views
  • Users 0 members are here
Related

Modifying the Petalinux Yocto recipe

Former Member

I would like to build a rootfs containing a bit more utilities, for example, a compiler and package manager.  Ideally I would like to load many support libraries to make the resulting image a bit more turn-key for my environment.  The default petalinux-configure for rootfs results in almost nothing installed even when development libraries are included.  For example, it seems to include libraries for apt-get/dpkg, but does not include the actual binary applications.

When I build the system, I simply used petalinux-build, no options, to build all components including the rootfs.  Could that be the reason why dpkg, etc., are not being installed on the rootfs too?

Consequently, does anyone know where the Yocto recipe is for the petalinux-* tools?  That might be of more utility.

Parents
  • 0

    Hi btgoodwin,
    my problem is similar, because I need to have gcc on Petalinux to execute OpenMp libraries.
    Have you solved with "cross-compile of a compile"?
    Thank you.

    Giacomo

  • 0 in reply to Former Member

    Sadly, no.  Ultimately we had to go through a process of split installation.  First we generated the petalinux filesystem for the part of our team interested in using OpenCPI, and then we had to cross-compile GCC, Make, Autoconf, etc. to seed the filesystem with enough build tools to natively compile the rest of the system.

    The big hoop to all of this is how to deal with the default volatile filesystem.  Ultimately we modified the u-boot parameters to drop the volatile one and use only our non-volatile copy from a separate partition.  This was only part of the battle though since those aforementioned tools must have the filesystem path compiled into them.

    To hack around this, we re-mounted the root file system onto itself in the same location as found on the host system.  For example, if the host found the root file system at /media/rootfs, then on the native system we also added an fstab entry for the same.  This allowed all these baked-in paths to gel once we went to the native compiling.

    It's not a good solution, nor a pretty one.  But it worked in lieu of finding others in the mean time.

Reply
  • 0 in reply to Former Member

    Sadly, no.  Ultimately we had to go through a process of split installation.  First we generated the petalinux filesystem for the part of our team interested in using OpenCPI, and then we had to cross-compile GCC, Make, Autoconf, etc. to seed the filesystem with enough build tools to natively compile the rest of the system.

    The big hoop to all of this is how to deal with the default volatile filesystem.  Ultimately we modified the u-boot parameters to drop the volatile one and use only our non-volatile copy from a separate partition.  This was only part of the battle though since those aforementioned tools must have the filesystem path compiled into them.

    To hack around this, we re-mounted the root file system onto itself in the same location as found on the host system.  For example, if the host found the root file system at /media/rootfs, then on the native system we also added an fstab entry for the same.  This allowed all these baked-in paths to gel once we went to the native compiling.

    It's not a good solution, nor a pretty one.  But it worked in lieu of finding others in the mean time.

Children