How does "bitbake virtual/kernel" work if kernel recipes don't have PROVIDES variable set to virtual/kernel?

user_14666607 0
Viewed 1850

I'm trying to understand a few pieces associated with using bitbake to compile the linux image and generating a boot image that would be used to flash onto the processor.

  • How come bitbake virtual/kernel really works? Read through section 2.3 and it says recipes use PROVIDES parameter to add an extra provider, which indicates a recipe could be called in multiple ways (by its name, and by whatever PROVIDES is set to). But the kernel recipes (../poky/meta-bsp/recipes-kernel) I checked didn't have PROVIDES parameter let alone it being set to virtual/kernel.
  • Upon running bitbake virtual/kernel, how come a boot.img is being generated when it should only just be generating a linux binary i.e vmlinux for instance? In one of the kernel .inc files, I see:
DEPENDS += " mkbootimg-native openssl-native kern-tools-native"
...
FILESPATH =+ "${WORKSPACE}:"
SRC_URI   =  "file://kernel \
              ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'file://systemd.cfg', '', d)} \
              ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'file://virtualization.cfg', '', d)} \
              ${@bb.utils.contains('DISTRO_FEATURES', 'nand-squashfs', 'file://squashfs.cfg', '', d)} \

mkbootimg-native I reckon refers to the boot image recipe that the kernel recipe depends on, though shouldn't it be the other way around since the boot image should contain the kernel image itself?

  • lastly, is there a way to put debug prints in different recipe files to see if it's being invoked? I tried echo...to no avail
bitbake yocto embedded-linux linux-kernel
1 Answers

The recipes you checked probably had PROVIDES. Most if not all kernel recipes inherit kernel class (directly or via some other classes, such as kernel-yocto). The kernel.bbclass actually specifies PROVIDES for you, c.f. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n8).

boot.img does not seem to be created by default for any machine. After a quick glance at the code, it seems that this is created by wic for images inheriting the image-live bbclass or by adding live to IMAGE_FSTYPES, c.f. http://docs.yoctoproject.org/ref-manual/classes.html#image-live-bbclass. From a simple git grep in the poky git repo, it seems only bootimg-efi.py is actually doing something with a boot.img which is called by wic when the -b or --bootimg-dir argument is passed, which is enforced when using wic. So probably the boot.img artifact is created only for EFI machines and images.

If you use echo or printf or similar shell functions (or print in Python tasks) in your tasks, you can only see them in ${WORKDIR}/temp/log.do_<task> of your recipe. Otherwise, you can use bbplain, bbnote, bbdebug, bbwarn, bberror or bbfatal. This will print to both the logs and the console (depending on your log level which is configurable with -D (the more Ds, the higher the log level)).

user_40634210
Related