[yocto] struggling with initramfs

[Zoran Stojsavljevic]

Hello to all,

I have my own YOCTO recipe how I do the initramfs.

Usually, some of these are missing in kernel .config file:

CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y

Please, check (they should be on) the CONFIG_DECOMPRESS_* options and if
not, please, turn them on.

To do this, please, for YOCTO use the following (to reconfigure kernel
.config):
bitbake -c menuconfig virtual/kernel

Also, in the local.conf I have the following set:

DISTRO_FEATURES_append = " ram"
IMAGE_FSTYPES_append = " cpio.xz"

Then I do: bitbake -k core-image-minimal, and from:
.../build/tmp/tmp/deploy/images/<platform_name>

Take my <initramfs_name>.cpio.xz as initramfs. Also, I take accordingly
zImage and .dtb files as well.

I prepend to initramfs.cpio.xz u-boot header:
mkimage -n 'Ramdisk Image'  -A arm -O linux -T ramdisk -C gzip -d
initramfs.cpio.xz initramfs.cpio.xz.uboot

And then write tiny U-Boot ash script to tftp (from host) all three files
to the target platform.

Works like a charm!

Zoran
_______


On Wed, Jul 4, 2018 at 8:57 PM, Ferry Toth <ftoth at telfort.nl> wrote:

> Tim Hammer wrote:
>
> > Can anyone point me to a step-by-step tutorial or simple how-to on
> > creating and using an initramfs with my kernel for ARM aarch64?
> >
> >
> > I have tried creating my own:
> >  - boot-image.bb file with IMAGE_FSTYPES = "cpio.gz".
> >  - local.conf has INITRAMFS_IMAGE_BUNDLE = "1"
> >  - linux.bbappend has INITRAMFS_IMAGE = "boot-image"
> >
> > This all seems to be "correct" to the extent that bitbake linux tries to
> > do the right thing.
> >
> > However, I get a failure in do_bundle_initramfs- "mv: cannot stat
> > 'arch/arm64/boot/Image': No such file or directory".
> >
> > To the best of my (limited) debugging abilities with Yocto, it seems like
> > the kernel image backup has already been run when it gets to this point
> > and the Image file in that directory has already been moved to Image.bak.
> > If I comment out the mv statement in kernel.bbclass causing the failure,
> > the process continues, but the initramfs does not seem to get populated
> or
> > perhaps installed into my kernel image as I get kernel panics that I have
> > been unable to get past.
> >
> >
> > I decided to take a different approach and try using the
> > core-image-minimal-initramfs recipe as INITRAMFS_IMAGE. By commenting out
> > the COMPATIBLE_HOST entry I am able to build a kernel for ARM aarch64. I
> > can even seem to boot into this initramfs- it counts down waiting for
> > removable media; seems to find my primary rootfs on sda3, but there is no
> > rootfs.img file there so says it is dropping to a shell (although I never
> > get a prompt...).
>
> We have taken this approach here
> https://github.com/edison-fw/meta-intel-edison/tree/master/
> meta-intel-edison-distro/recipes-core
>
> There are 2 images, the rootfs and the initramfs. And we overload the
> init-live.sh
> to load certain kernel modules and acpi-tables then switchroot to the
> rootfs.
>
> > Thinking I could start with that recipe and work to get rid of the live
> > stuff and just get to a busybox prompt before trying to run my unique
> init
> > commands, I copied  core-image-minimal-initramfs.bb to my-
> > core-image-minimal-initramfs.bb in my layer and changed INITRAMFS_IMAGE
> to
> > "my- core-image-minimal-initramfs".
> > However, I obviously missed something in the configuration as I get an
> > error in go_bundle_initramfs again:
> >      kernel-source/scripts/gen_initramfs_list.sh:
> >                  Cannot open
> > '/.../linux-qoriq/4.14-r0/build/usr/my-core-image-
> minimal-initramfs-{machine}.cpio'
> >
> > Any help would be greatly appreciated.
> > Thank you!
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180705/8a0c4e6b/attachment.html>