I'm building a yocto image to run on the Jetson Nano. Right now I'm working on a Jetson Nano devkit which boots from the SD-card, and the flashing is described on the meta-tegra GitHub repo wiki. It doesn't say how to flash onto the eMMC on the Jetson Nano, only on the SDcard.
Can I copy the yocto build rootfs to the nvidia_sdk L4T tools (replacing the 'rootfs' folder)? But what about the rest of the folders (bootloader, kernel, lib, nv_tegra)? It should be the same binaries, I'm just not so sure the kernel and bootloader is the same, and don't really know about the rest.
Anyone dealing with the same issue or, even better, found a way to do this, please let me know.
I had a conversation with the maintainer of the meta-tegra layer and ended up with creating a new machine configuration:
##TYPE: Machine
##NAME: Nvidia Jetson Nano
##DESCRIPTION: Nvidia Jetson Nano prod board
KERNEL_ARGS ?= "console=ttyS0,115200 console=tty0 fbcon=map:0 net.ifnames=0"
KERNEL_ROOTSPEC ?= "root=/dev/mmcblk0p${#uboot_var('distro_bootpart')} rw rootwait"
IMAGE_ROOTFS_ALIGNMENT ?= "1024"
require conf/machine/include/tegra210.inc
KERNEL_DEVICETREE ?= "_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0002-p3449-0000-b00.dtb"
MACHINE_FEATURES += "ext2 ext3 vfat"
UBOOT_MACHINE = "p3450-porg_defconfig"
EMMC_SIZE ?= "17179869184"
EMMC_DEVSECT_SIZE ?= "512"
BOOTPART_SIZE ?= ""
BOOTPART_LIMIT ?= "10485760"
ROOTFSPART_SIZE ?= "3221225472"
ODMDATA ?= "0x94000"
EMMC_BCT ?= "P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg"
NVIDIA_BOARD ?= "t210ref"
NVIDIA_PRODUCT ?= "p3450-porg"
NVIDIA_BOARD_CFG ?= ""
TEGRA210_REDUNDANT_BOOT ?= "0"
PARTITION_LAYOUT_TEMPLATE ?= "flash_l4t_t210_emmc_p3448.xml"
TEGRA_SPIFLASH_BOOT ?= "0"
TEGRA_FAB ?= "300"
TEGRA_BOARDID ?= "3448"
The machine configuration is almost identical to the devkit's, but some parts had to be changed to match to Jetson Nano Production Module configurations, i.e. change the KERNEL_DEVICETREE the the one matching the newer eMMC Jetson Nano and change TEGRA_FAB accordingly. Then change the PARTITION_LAYOUT_TEMPLATE to match the emmc layout instead of the spi_sd layout (the flash_l4t_t210_emmc_p3448 is the default p3448 emmc layout provided with meta-tegra).
After this, Yocto will produce a tegraflash zip that contains the necessary partition files and a rootfs image (along side some flashing tools). Put the Jetson Nano production module into recovery mode (FORCE RECOVERY + RESET), plug in the micro-usb cable and run the doflash.sh script to flash the nano, and voila.
Related
There are many kernel *.bb in
~/poky/meta/recipes-kernel/linux
I don't have PREFERRED_PROVIDER_virtual/kernel defined in local.conf
I also include meta-intel layer, I think meta-intel has it's kernel recipe also.
After built the yocto image, boot, and login, type 'uname -a' result is
Linux genericx86-64 5.4.20-yocto-standard xxxxx
I think yocto select it's poky kernel, but I can't find where this default setting located. ( which file setting this kernel )
Usually you can find it in the machine conf in :
meta-yourmeta/conf/machine/yourmachine.conf
The list of supported kernels by your machine is in recipes-kernel of your BSP.
It's set by MACHINE, if I'm not wrong.
If you are unsure of your setting of PREFERRED_PROVIDER_virtual/kernel you can also use bitbake -e <recipe> to see how it is set.
Poky itself has it defined with default value
poky/meta/conf/machine/include/qemu.inc:22:PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
poky/meta/conf/machine/include/x86-base.inc:20:PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
I'm creating a small Yocto distro that should work in RAM on tmpfs. I use the WIC configuration in the following way:
part /boot --source bootimg-efi --sourceparams="loader=grub-efi,initrd=${PN}-${MACHINE}.cpio.gz,file=${PN}-${MACHINE}.cpio.gz" --ondisk sda --label msdos --active --align 1024
bootloader --ptable gpt --timeout=0 --append="rootfstype=tmpfs rootflags=size=2G console=ttyS0,115200 console=tty0"
I also add IMAGE_FSTYPES_append = " cpio.gz " to my local.conf, so it builds the cpio.gz archive from my rootfs.
My problem is very straightforward - when WIC runs, it tries to create the wic file before it is done with creating the rootfs cpio.gz, and therefore the build fails. What I need is to create a dependency, something that will hold WIC scripts until the cpio.gz is ready. Does anyone know how to achieve it? Can, for instance, WKS_FILE_DEPENDS be used?
Here is the failure:
| ERROR: _exec_cmd: cp .../poky/build/tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.cpio.gz .../poky/build/tmp/work/genericx86_64-poky-linux/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/core-image-minimal-genericx86-64-20191121151711/tmp.wic.k00ckxmk/hdd/boot returned '1' instead of 0
| output: cp: cannot stat '.../poky/build/tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.cpio.gz': No such file or directory
Currently I bypass the problem by running the wic tool manually after the build. I had to use IMAGE_FSTYPES_remove = " wic wic.bmap hddimg " in my local.conf for that. The command for running wic then is:
wic create ../meta-mylayer/wic/myimage.wks -e core-image-minimal
Thanks!
EDIT:
Maybe the problem is not in creating the required dependency, but in the way I create the image? I just want a UEFI boot, a kernel, and a cpio.gz file with a complete rootfs which will gets mounted on boot. This is not an initramfs, but a complete rootfs that I need there. Except the problematic dependency the resulting image does exactly what I need.
You can specify the dependency with WIC in 2 ways.
Using do_image_wic: The final task to create the WIC is do_image_wic. So you can add dependency for creating your initrd/initramfs image to this task as below,
do_image_wic[depends] += "image-base-initramfs:do_image_complete"
You need to specify this in your WIC image creation recipe. For this example,
DESCRIPTION = "My image"
inherit core-image
export IMAGE_BASENAME = "image-base"
IMAGE_FSTYPES = "wic.xz"
DEPENDS += "image-base-initramfs"
do_image_wic[depends] += "image-base-initramfs:do_image_complete"
WKS_FILES = "my.wks"
Here image-base is used for creating the WIC using my.wks. It waits for the initramfs to complete the building. In image-base-initramfs you will create the initramfs image.
To add, you can also do this with INITRAMFS_IMAGE when using kernel fitImage.
Using WKS_FILE_DEPENDS: You can add any bitbake recipe to dependency before creating the WIC image. Adding image-base-initramfs to this variable will wait for it to complete the initramfs image. We also have WKS_FILE_DEPENDS_BOOTLOADERS when depending on bootloader to complete in WIC creation.
I'm trying to add auditd to Yocto linux.
I added the selinux layer and it's dependent layers: openembedded-core and meta-virtualization.
I added the layers to bblayers.conf.
I added DISTRO_FEATURES_append = " acl xattr pam selinux"
and PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls" to the local.conf file.
After building (by using bitbake core-image-base) and running the qemu, the kauditd process is running, but all user-space tools are not.
The /etc/audit folder is not exist ,non of the audit's config files exists (audit.rules) and no user-space audit process is running.
In the layer's info it is declared - "User space tools for kernel auditing".
What I am missing?
Thanks.
I think I found something that will answer your question: If you know what an example binary or library you expect to be in the target image, you can find what recipe the executable is in, and then add that package to the image.
Start with the name of a binary or library you expect to be in the image and run the following. For me, I am using a CAN bus executable called candump. I wonder what recipe it's in? To find out, I issue:
devtool search candump
Which returns:
can-utils
If nothing is returned, I'd double check your conf/bblayers.conf so that the layer you think it may be in is actually being seen by your build system. If you are unsure, take a look at the link below which points to OpenEmbedded which has a handy search utility for packages.
After you find the recipe, you can then include that recipe into your build.
Here is a good reference in doing what I think you're asking on the OpenEmbedded website:
https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image
I just added auditd to my system. This is what I did.
First I got the repository checked out.
cd /path/to/yocto
git clone git://git.yoctoproject.org/meta-selinux
cd meta-selinux
# checkout the branch matching the Yocto release you are on
git checkout thud
Then I added auditd to my build.
cd /path/to/build
bitbake-layers add-layer /path/to/yocto/meta-selinux
cat >> conf/local.conf <<'END'
IMAGE_INSTALL_append = " auditd"
END
bitbake my_normal_image_target
Even though the Yocto recipe is called audit, the package name is auditd.
Of course, auditd without selinux is useless but it did attempt to run (journalctl -u auditd) and /etc/audit exists.
FWIW: To get auditd to a point where it reports say, login success/failure, I had to do a few more things. I'm not just adding it to a standard Yocto image, but to a custom image and custom machine. I'm already using systemd so I didn't have to change that (the layer seems to indicate it's required?). My local.conf looked like this.
# enable selinux
DISTRO_FEATURES_append = " acl xattr pam selinux"
# set the policy
PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
# install selinux packages and auditd
IMAGE_INSTALL_append = " packagegroup-core-selinux auditd"
# tell the kernel to enable selinux (non-enforcing) and audting
APPEND_append = " selinux=1 enforcing=0 audit=1"
I also had to change linux-yocto_selinux.inc to load selinux.cfg later. Probably layer/recipe ordering could have solved this too?
-SRC_URI += "${#bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}"
+SRC_URI_append = "${#bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}"
With all that in place, I see audit logs in my journal.
i'm trying to get the PRU enabled in yocto (morty) for the beaglebone black, however i get the following error:
ERROR: pru-icss was skipped: incompatible with machine beaglebone (not in COMPATIBLE_MACHINE)
these are my layers:
BBLAYERS ?= " \/home/auke/workspace/yocto/poky/meta \
/home/auke/workspace/yocto/poky/meta-poky \
/home/auke/workspace/yocto/poky/meta-yocto-bsp \
/home/auke/workspace/yocto/layers/meta-bbb \
/home/auke/workspace/yocto/layers/meta-qt5 \
/home/auke/workspace/yocto/layers/meta-openembedded/meta-networking \
/home/auke/workspace/yocto/layers/meta-openembedded/meta-oe \
/home/auke/workspace/yocto/layers/meta-openembedded/meta-python \
/home/auke/workspace/yocto/layers/meta-ti \
"
which are all in the morty branch.
The package depends on the following
recipes-bsp/pru/pru-icss_git.bb:COMPATIBLE_MACHINE = "ti33x|ti43x|omap-a15|k2g"
My question is, how can i configure the MACHINE ?= "beaglebone" variable in my local.conf such that it includes the ti33x.
Avoid having both meta-yocto-bsp and meta-ti in your bblayers.conf!
Both of these two layers are BSP-layers that defines a beaglebone machine.
In meta-ti, the beaglebone machine is part of ti33x, however, the meta-yocto-bsp version of beaglebone doesn't know anything of ti33x (which in turn is defined in meta-ti).
Thus, you bblayers.conf mixes those two machines with an identical name. The solution for you is to remove meta-yocto-bsp, as you want eg pru-stuff from meta-ti.
I would like to create a new target based on core-image-minimal and I would like to change the init system with systemd over SysV init. I would like my change to be permanent (nothing based on local.conf). How can I do this?
Edit: As Anders pointed out in the comments, i was wrong:
The available init systems are set in the local.conf, but you can indeed change the init system on a per image basis. In your case you want to change it in core-image-minimal. This image installs packagegroup-core-boot which sets
VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
VIRTUAL-RUNTIME_initscripts ?= "initscripts"
You could create your own packagegroup-core-boot-systemd where those variables are set to
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
and install it to your target.
The configuration of the init system is a Distro Feature. That means it is not in the image recipe, but in the local.conf.
If you don't want to put the configuration in the local.conf, you could create a custom distro configuration with the settings in it. The only thing you have to change in the local.conf is the line
# DISTRO = poky
DISTRO = <custom-distro>
The reference manual has also a chapter on creating your own distro