Yocto: No recipes available (tegra) - embedded-linux

I'm attempting to create an image with
bitbake core-image-minimal
For my jetson nano (nvidia tegra). I've added the meta-layer for tegra devices from https://github.com/madisongh/meta-tegra
and added it to bblayer.conf. I have also added lines
IMAGE_CLASSES += "image_types_tegra"
IMAGE_FSTYPES = "tegraflash"
to the local.conf file to be able to flash it later.
When I attempt to run the bitbake command to create the image, I get the error message:
ERROR: No recipes available for:
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/vulkan/vulkan-loader_1.1.%.bbappend
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/vulkan/vulkan-tools_1.1.%.bbappend
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/wayland/weston_7.0.0.bbappend
But aren't the files it says there is no recipes for the same recipes it's looking for? Isn't "vulkan-loader_1.1.%.bbappend" a recipe?
How do I solve this problem? Is it because it can't find the files or is the bbappend not the recipes but something else?

Michael,
I don't have an answer for the vulkan pieces but I do have a few pointers since we seem to be going down a similar path with the nano.
Use the warrior branch of yocto
You'll need to download the binary pieces of the nvidia sdk through the SDK manager
Point to these sdk packages in your local.conf with the NVIDIA_DEVNET_MIRROR variable. ex: "file:///home/nvidia/yocto/git/poky/devnet/nano-dev"
Because of the binary pieces in step 2, you need to use an older gcc version which isn't really supported in warrior. I used the linaro-7.2 layer.
Since gcc7 is not supported in warrior, yocto / openembedded will attempt to pass flags to gcc which will make the build fail. Here's a summary, which I hope is complete, to help you through this.
Add DEBUG_PREFIX_MAP="" to local.conf and apply the following patch.
diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 174ce5a8c0..e8d651a010 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
## -128,7 +128,7 ## do_prepare_config () {
${S}/.config.oe-tmp > ${S}/.config
fi
sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -b"/' ${S}/.config
- sed -i 's|${DEBUG_PREFIX_MAP}||g' ${S}/.config
+ #sed -i 's|${DEBUG_PREFIX_MAP}||g' ${S}/.config
}
# returns all the elements from the src uri that are .cfg files
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.bb b/meta/recipes-core/libxcrypt/libxcrypt.bb
index 3b9af6d739..350f7807a7 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.bb
+++ b/meta/recipes-core/libxcrypt/libxcrypt.bb
## -24,7 +24,7 ## FILES_${PN} = "${libdir}/libcrypt*.so.* ${libdir}/libcrypt-*.so ${libdir}/libowc
S = "${WORKDIR}/git"
BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE} -std=gnu99"
-TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} -Wno-error=missing-attributes"
-CPPFLAGS_append_class-nativesdk = " -Wno-error=missing-attributes"
+TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} "
+CPPFLAGS_append_class-nativesdk = " "
BBCLASSEXTEND = "nativesdk"
Best of luck! I apologize if this is a bit rough, but I'm just getting through this myself.

I deleted everything and started with a fresh build, did the EXACT same procedure and added all the same lines to the local.conf and bblayer.conf... But this time, bitbake command is running with no errors at all.

Related

Files are not installed from recipe

I'm trying to create a custom recipe to sign a u-boot image generated from u-boot.bb.
I have 2 custom recipes:
1. u-boot.bb - clones, compiles and deploys u-boot resulting u-boot.elf.
2. u-boot-sign.bb - depends on u-boot.bb. Gets u-boot.elf, passes it through
custom signing procedure and deploys the result.
For signing I am forced to use a custom procedure which is in a form of python scripts located in external repository.
The part which causes a problem is accessing a deployed u-boot.elf binary file from u-boot.bb recipe. I cannot find a way to expose u-boot.elf binary file to a u-boot-sign.bb recipe.
What should be the correct way of exposing an image binary file from one recipe, to be accessed, signed and deployed in another recipe?
For the purpose of sharing the files between recipes and between cross-compilation scope, I used ${datadir} when installing the binaries (via do_install). This allowed me to access all files described by FILES:${PN} via recipe-sysroot.
u-boot.bb - exporting recipe:
…
do_install() {
install -d ${D}${datadir}/u-boot-2016/
install -m 0644 ${B}/${UBOOT_ELF_BINARY} ${D}${datadir}/u-boot-2016
}
FILES:${PN} = "${datadir}/u-boot-2016"
…
u-boot-sign.bb - depending recipe
…
DEPENDS += " u-boot python3-native"
do_sign() {
${STAGING_BINDIR_NATIVE}/python3-native/python3 sign.py \
-i ${RECIPE_SYSROOT}${datadir}/u-boot-2016/${UBOOT_ELF_BINARY}
}
…
Inspiration from Here
Edit
I was advised not to transfer files like this using ${datadir}. For intermediate files the better approach would be to use to use /firmware as it is done in meta-arm.
u-boot.bb - exporting recipe:
…
do_install() {
install -D -p -m 0644 ${B}/${UBOOT_ELF_BINARY} ${D}/firmware/${UBOOT_ELF_BINARY}
}
FILES:${PN} = "/firmware"
SYSROOT_DIRS += "/firmware"
…
u-boot-sign.bb - depending recipe
…
DEPENDS += " u-boot python3-native"
do_sign() {
${STAGING_BINDIR_NATIVE}/python3-native/python3 sign.py \
-i ${RECIPE_SYSROOT}/firmware/u-boot-2016/${UBOOT_ELF_BINARY}
}
…
It also requires to add /firmware to SYSROOT_DIRS.

Create PCL by hand?

Is it more or less feasible to create PCL files "artisanally", by hand? I have done it for PostScript and found it not particularly difficult, though it takes a lot of time and effort to create even a simple drawing. Now I am faced with an OKI C823 that is connected to an Ubuntu PC, it prints ok but does not understand PostScript - which might explain why it was so inexpensive... (for such a big printer)
I did find the below sample in the "PCL XL Feature Reference" but when I fed it to the printer, the text just printed as text instead of drawing the intended line.
eInch Measure
600 600 UnitsPerMeasure
BeginSession // attribute: basic measure for the session is inches
// attribute: 600 units in both X and Y direction
// operator: begin the imaging session
ePortraitOrientation Orientation
eLetterPaper MediaSize
BeginPage // attribute: page orientation is portrait
// attribute: size of media for page is letter
// operator: begin the page description
1200 800 Point
SetCursor // attribute: point a which to set the current cursor
// operator: set the cursor
2400 800 EndPoint
LinePath // attribute: endpoint of a 2 inch line
// operator: add the line to the current path
PaintPath // operator: paint the current path
EndPage // operator: end the page description
EndSession // operator: end the imaging session
Edit
You can convert ps to pcl with ghostscript
sudo apt-get install ghostscript
gs -o ~/test.pcl -sDEVICE=pxlcolor -f ~/test.ps
or
gs -o ~/test.pcl -sDEVICE=pxlmono -f ~/test.ps
If you need to go backward for some reason--convert pcl to ps--then see the more complicated instructions below
You can convert from pcl6 to ps using GhostPDL from Ghostscript. It's a separate product from Ghostscript, and afaik the only way to install it is to build it from source.
Build It
I'm using ubuntu 18 LTS.
some prereqs I needed, your system might already have them
sudo apt-get install autoconf
sudo apt-get install g++
sudo apt-get install make
download the source, untar, and build
wget https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs950/ghostpdl-9.50.tar.gz
tar xvf ghostpdl-9.50.tar.gz
cd ghostpdl-9.50
sh ./autogen.sh
make
The binaries are in the bin folder
cd ./bin
Sample Usage
I copied a test.ps file from wikipedia that prints "Hello World" in courier.
Convert ps to pcl, convert the pcl back to pdf
./gs -o ~/test.pcl -sDEVICE=pxlcolor -f ~/test.ps
./gpcl6 -o ~/test.pdf -sDEVICE=pdfwrite ~/test.pcl
And everything worked as expected.

bitbake not producing a zImage file

I've been running a Yocto build in bitbake for a few days, but I've noticed it sometimes stops producing the zImage file of my kernel. Most of the changes I'm making are to the kernel config, and the machine.conf file. when this happens, I still get updated tar.gz files with each build, but the zImage stops being updated. Running the do_clean, do_cleanall and do_cleansstate tasks do not help, and neither does deleting the old zImage file from build/tmp/deploy. The only thing that helps is deleting the entire pocky/build/tmp directory and rebuilding the entire project from scratch. Here is my current machine.conf file:
##TYPE: Machine
##Name: EMAC, Inc. SoM-9G45M Module
##DESCRIPTION: Machine.inc configuration for the SoM-9G45M board with a at91sam9g45 processor
TARGET_ARCH = "arm"
PREFERRED_PROVIDER_virtual/kernel = "linux-2.6.30-at91-emac"
PREFERRED_PROVIDER_xserver = "xserver-kdrive"
KERNEL_IMAGETYPE = "zImage"
KERNEL_EXTRA_ARGS = "LOADADDR=0x74000000"
#don't try to access tty1
USE_VT = "0"
MACHINE_FEATURES = "kernel26 apm alsa ext2 usbhost usbgadget"
KERNEL_DEVICETREE = "at91som9g45.dtb"
# used by sysvinit_2
#SERIAL_CONSOLE = "115200 ttyS1"
SERIAL_CONSOLE = "115200 ttyS0"
#SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
#SYSLINUX_DEFAULT_CONSOLE = "console=ttyS0"
#SYSLINUX_SERIAL = "0 115200"
#SYSLINUX_SERIAL_TTY = "console=ttyS0,115200"
#EXTRA_IMAGECMD_jffs2 = "--pad=0xA00000 --little-endian --eraseblock=0x20000"
# NAND
MKUBIFS_ARGS = " -e 129024 -c 2047 -m 2048 -x lzo"
UBINIZE_ARGS = " -m 2048 -p 128KiB -s 512"
UBI_VOLNAME = "rootfs"
UBOOT_MACHINE = "${MACHINE}_nandflash_config"
UBOOT_ENTRYPOINT = "0x74000000"
UBOOT_LOADADDRESS = "0x74000000"
require include/at91sam9.inc
What can cause a bitbake build to stop producing the specified kernel image, and how do I fix it?
The answer ended up having two parts.
First, running bitbake -c do_cleansstate linux-at91 and then bitbake core-image-sato successfully regenerated the zImage file.
Second, linux-2.6.30-at91-emac was incorrect since my kerenl was just called linux-at91. So my kernel build was likely only being run when I ran builds for other machines.
So my full image build wasn't rebuilding the kernel because I had referenced a different kernel. Once I fixed that, the kernel build would start running again. I'm not sure how I got a zImage in the first place, or why bitbake never threw an error after being told to build a kernel that didn't exist.

Accessing initramfs-tools features in Yocto generated initramfs image

I would like to load a few kernel modules, and activate framebuffer access prior to Plymouth launch. This is normally done using /etc/initramfs-tools directory provided with the initramfs-tools. However, when building an initramfs image with Yocto, no such directory is available. This means that whatever initramfs-tools does for loading modules and initializing framebuffer, has to be done manually in the initramfs image as far as I could understand.
The tasks I want to accomplish is very delicately explained by notro in https://github.com/notro/fbtft/wiki/Bootsplash
. I'd like to do the equivalent of what's done below:
Access to /etc/initramfs-tools/scripts/init-top/spi and modprobe a module.
Access to /etc/initramfs-tools/modules and list further modules to be launched by modules daemon
Enable framebuffer which is done via echo "export FRAMEBUFFER=/dev/fb1" | sudo tee /etc/initramfs-tools/conf.d/fb1
With my research, I could find initramfs-framework-base package which features some scripts that initramfs boot uses. I think this might be a good starting point. However, I do not know how to explicitly tell initramfs to do what I want to accomplish (tasks above).
Note: Currently, my initramfs image is generated by the following recipe:
include recipes-core/images/rpi-basic-image.bb
BASEPACKS = " \
base-passwd \
busybox \
initramfs-live-boot \
initramfs-framework-base \
udev \
${ROOTFS_BOOTSTRAP_INSTALL} \
"
IMAGE_INSTALL = " ${BASEPACKS} \
plymouth plymouth-set-default-theme \
"
# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = "splash"
SPLASH = "plymouth"
IMAGE_LINGUAS = ""
LICENSE = "MIT"
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
IMAGE_ROOTFS_SIZE = "8192"
IMAGE_OVERHEAD_FACTOR = "1.0"
IMAGE_ROOTFS_EXTRA_SPACE = "0"
IMAGE_ROOTFS_MAXSIZE = "12288"
CMDLINE_append = " quiet splash nomodeset plymouth.ignore-serial-consoles consoleblank=0"
BAD_RECOMMENDATIONS += "busybox-syslog"
Also Note: I'm using an ARMv6-based machine with U-boot bootloader. Compiling the original initramfs-tools (that is originally developed for Debian) generates 0 byte images. I'm guessing this is an issue with its compatibility. So I'll have to resort to generating initramfs with yocto's internal tools.
Any help is appreciated. Thanks in advance.

Steps for installing Orbfit 4.2

I'm trying to install Orbfit4.2 on a using linux mint maya edition. I'm trying to follow the on line help. I have unzipped the tared file, configured with $ ./config -0 gfortran and then $ make. Both appears to be successful. I am now trying to create the DE405 data files in the /orbfit/src/jpleph directory. I have downloaded the header.405 and the ascp*date* ascii files into the directory from JPL. I have run $ make ephemerides and get the following;
cat header.405 ascp1960.405 ascp1980.405 ascp2000.405 ascp2020.405> input.430
asc2eph.x < input.430
/bin/sh: 1: asc2eph.x: not found
make: *** [ephemerides] Error 127
(I have also used input value of 405 instead of 430)
I have also tried just running from with in
the directory
$ ./asc2eph.x which was the previous method before the Makefile was included. All I get with this is 'authors' introductory message and the flashing working box-still running 6 hrs later.
If anybody has any experience or advice with installing Orbfit 4.2 from the start or can help me move on from the above blockage I would appreciate.
Note I am a real novice and would appreciate idiot step by step guide- I'm the idiot.
Eric
The Makefile assumes that the current directory "." is in your path. This is a security risk. You can either edit the Makefile to rename these binaries:
$ diff -u Makefile.orig Makefile
--- Makefile.orig 2014-01-09 07:14:10.000000000 -0800
+++ Makefile 2014-10-21 11:40:00.850236839 -0700
## -10,7 +10,7 ##
make clean
ephemerides: input asc2eph.x
- asc2eph.x < input.430
+ ./asc2eph.x < input.430
mv JPLEPH jpleph
make clean
Or you can add . to your path (but this is insecure!) by doing
$ PATH=.:$PATH

Resources