> There is no standard distro feature called "ram". Perhaps this is > something specific to your BSP layer?
Yeah, I noticed that. There is " nfs" parameter, but looks somehow peculiar: not in line with initramfs creation. I know that the whole line: DISTRO_FEATURES_append = " ram" looks bogus/useless, but YOCTO build system does not complain either. Maybe, you YOCTO guys, you do want to do some action about it? ;-) > This advice and these instructions are all fine. However, just for the > record, creating a standalone cpio archive and arranging for the > bootloader to load the kernel and cpio archive into DRAM as separate > images before booting the kernel is not solving the same problem as > embedding a cpio archive inside the kernel image via OE's > INITRAMFS_IMAGE_BUNDLE option. Another excellent observation! I do create test creations, mainly test vehicles for the boards/platforms these days. And for this, better to have splited zImage and initramfs.cpio.xz. The reason is very obvious: this is the scalability problem, and sometimes I need/require to swap parts in this equation! If the final production image is to be prepared, especially for final static rootfs-es with well defined applications on hard drives, the bundle (kernel+initramfs) will be just fine/excellent transient solution! Zoran _______ On Fri, Jul 6, 2018 at 3:13 AM, Andre McCurdy <armccu...@gmail.com> wrote: > On Wed, Jul 4, 2018 at 11:23 PM, Zoran Stojsavljevic > <zoran.stojsavlje...@gmail.com> wrote: >> 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" > > There is no standard distro feature called "ram". Perhaps this is > something specific to your BSP layer? > >> 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. > > This advice and these instructions are all fine. However, just for the > record, creating a standalone cpio archive and arranging for the > bootloader to load the kernel and cpio archive into DRAM as separate > images before booting the kernel is not solving the same problem as > embedding a cpio archive inside the kernel image via OE's > INITRAMFS_IMAGE_BUNDLE option. > >> On Wed, Jul 4, 2018 at 8:57 PM, Ferry Toth <ft...@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@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >> >> -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
