Posts by bkeohane

Hello,

I've built a core-image-minimal-initramfs image to test its deployment in RAM, and I changed the image type to:

I changed the fdt variable to:

I have created a NAND partition "RamDisk", I download and store the initramfs image to RAM address 0x13000000, and I write it to this partition.

I have also changed the variable:

When I boot, I run into the following:

But when the actual rootfs shall be mounted, there is an issue:

If I set the rootfs variable back to default:

The ramdisk image is still successfully read, bit this time, the boot sequence runs into:

I assume, there is a problem with handing over from the initramfs to the actual rootfs. Any suggestions?

Thanks!

Bjørn

I changed

to

which works.

I realized, when creating the rootfs on TargetFS partition, the size is not set correctly. A reboot after setting the partitions solved this issue.

The topic can be regarded as closed,

I have found the variable

I assume, this needs to be changed, too?

Hello,

thank you for your answer.

I have setup the partition table accordingly, using the mtdparts env variable:

and I changed fdtaddr to 0x13000000:

However, after installing the new Kernel image, and reinstalling FDT and rootfs image, I run into an error:

It is weird, that it seems to still look for a FDT at 0x12000000:

May this be the issue? I used the command:

to install the FDT. It seems counterintuitive, since the $loadaddr variable holds the address 0x11000000, but the output of writing to NAND was:

So, it did write to the correct offset, as it seems.

Is there any other address I need to change, or maybe I should use the command:

Thanks again for your support.

Hello,

I have built an Kernel image with a bundled initramfs, to show a bootscreen very early using Plymouth. The Kernel image is about 20 MB in size. The default partition size for the Kernel (address $Kernel in U-Boot) is 7 MB in size.

I have repartitioned the Kernel partition using mkpart in U-Boot, by taking some memory space from the TargetFS. I made sure, the offsets and sizes of all partitions fit. When downloading and installing the Kernel image incl. initramfs to my Kernel partition, I boot into a kernel panic.

Is there any reason behind this? I asked myself, can I not modify the partitions and its sizes inside a Yocto layer, by e.g., patching the u-boot configuration file (fsimx6.h)?

Any hint on partitioning and making the bundled kernel image run would be helpful!

Thank you.

Hi,

thank you for the detailed answer. I now see the problem is of bigger concern.

However, I could successfully build an initramfs, bundled with the Kernel in a single image. I use this recipe in my custom layer, and I use Plymouth for bootscreen.

The init file is a simple bash script.

The spinner theme and all its coresponding files were already located on the Fedora VM.

Of course, one needs to activate the initramfs support in the Kernel configuration.

This page also gives some hints: 12 Building — The Yocto Project ® 5.1.999 documentation

Thanks.

Hello,

thank you for your answer.

I made the experience, that fbsplash and plymouth both do not start as early in the boot process as the penguins logos used to show up.

I use a systemd service to start the fbsplash.sh script very early:

It works, but there are several seconds of black screen until the ppm file appears.

----

The same if true for Plymouth, but here, it completely fails to run at boot.

Plymouth-start.service:

I also set the UBoot bootargs to:

and I changed the plymouth.conf file to:

Once the eFus has fully booted, I can manually run the plymouth splashscreen by restarting the plymouth.start.service, but it fails to appear directly after UBoot exited and the Kernel boot sequence is running.

Is there a configuration I am missing?

What file format shall one use to load an image from RAM to the bootloader using splashprepare/splashimage?

I use a 8bit Bitmap, and it is not shown in original colors. I compressed it to RLE, but UBoot says:

Error: compression type 1 not supported

Thank you.

My display is working without the patch, but I will test it.

Is there also a way to replace the penguins with a custom image?

is this solution still valid under fsimx6-Y2024.04 for eFus i.MX6 Quad? And does it get rid of the penguins?

Hi,

than ks for the answer, I could resolve the issue by defining the relevant pins as LED GPIOs in the efusa9qdl.dtsi file, which I can then toggle via sysfs:

and then assigning the pin control:

This works good. The issue can be regarded as resolved, but I will consider and try using gpiohog, to have them in /sys/class/gpio rather than /sys/class/led. Thanks!

Hello,

I have overseen the part in the docs, where the mapping between the J1 pins and the GPIOs is done. This works fine now.

Quote

Example

On PicoCoreMX8MP, use pin GPIO_1_54 on feature connector as output pin. This is pin 54

on the PicoCoreBBDSI connector J1, also available on pin 8 of the feature connector J11 on

the PicoCoreBBDSI SKIT. The “GPIO Reference Card” for PicoCoreMX8MP in the row GPIO

the GPIO1_IO1 which means that this GPIO is on gpiochip1 the IO number 1.

However, setting GPIOs HIGH or LOW is not working with the libgpiod toolI have installed. I checked the version, and it is v1.6.3.

With what version of the libgpiod tool has the eFusA9R2Q been tested?

Tah!

Hi,

the issue is resolved by using the package libgpiod by libgpiod in Yocto (interelectronix.com).

Here, it is decreibed how to install the package in y Yocto build.

My goal is, to use the GPIOs 65 (SD_B_DAT2), 67 (SD_B_DAT3), 77 (SD_B_DAT0), and 79 (SD_B_DAT1) for controlling the shutdown control, mute control and gain signals for an external audio channel (on a custom baseboard, not the SINTF), which shall output audio files to an exciter.

The GPIOs numbered earlier are being used by the SD_B SD card port, hence, I have commendted out the defines in the device tree source file, by using a patch:

Using /sys/class/gpio, to manually set the GPIOs did not do the trick, I believe, because it is deprecated in kernel versions 5.15.

However, the GPIO reference card (for both, efusa9 and efusa9r2) do not provide the mapping between the gpiochip# numbers and lines printed by

and the actual GPIO pins on the board, rather only the mapping for using /sys/class/gpio.

I have attached the output of my gpioinfo command to this post.

How is the mapping between the GPIOs and the gpiochip# numbers and lines done for this package, e.g., what J1 pin corresponds to which gpiochip and line?

Hi,

I am using fsimx6-Y2024.04 Release, which should have kernel version 5.15.

I want to use the GPIOs, as shown in the documentation "Linux on FS Boards", page 134.

The way of using /sys/class/gpio is marked as deprecated for kernel version 5.15, and I am told to use libgpio-tools and gpiodetect instead.

But this package and the command are not available in my built image.

Do I need to install it when building the image with yocto?

Thanks!

Good morning,

yes, I have set up the Kit (Qt Version, compiler, debugger, cmake) as stated in the documentary, pointing to the SDK in /opt/fus-imx-wayland/5.15-kirkstone/sysroots/x86_64-pokysdk-linux/.

I could get rid of the errors I posted before, by setting the CMAKE_SYSROOT variable.

Furthermore, I explicitly set the target architecture and FPU (floating point unit), since I experienced errors stating, that the FPU for the target was not set:

Just to make sure, I also specified the installation directory on the target conditionally, just as it is suggested to do in a .pro-file, if qmake is used

However, the error I see after adjusting these settings in my CMakeLists.txt file, are now of a nature of missing dependencies, I assume. I have attached the error output to this post.

The line, the error message points to in CMakeLists.txt:10, reads:

In the attached cmake error output, the lines

• Line 40: CMake Warning at /opt/fus-imx-wayland/5.15-kirkstone/sysroots/x86_64-pokysdk-linux/usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
  Found package configuration file:
  /opt/fus-imx-wayland/5.15-kirkstone/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/cmake/Qt6Core/Qt6CoreConfig.cmake
  but it set Qt6Core_FOUND to FALSE so package "Qt6Core" is considered to be NOT FOUND.
• Line 55: CMake Warning at /opt/fus-imx-wayland/5.15-kirkstone/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/cmake/Qt6/Qt6Config.cmake:223 (find_package):
  Found package configuration file:
  /opt/fus-imx-wayland/5.15-kirkstone/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/cmake/Qt6Quick/Qt6QuickConfig.cmake
  but it set Qt6Quick_FOUND to FALSE so package "Qt6Quick" is considered to be NOT FOUND.

make me suspecting, there is some sort of misconfiguration of CMake, not finding the QtCore and QtQuick packages.

I checked, the Qt6CoreConfig.cmake and Qt6QuickConfig.cmake files are located at the correct path.

I checked the Qt6Config.cmake at line 223 (first error in call stacks), and it failes at the find_package command.

I will investigate further today, but any hints, tips or black magic will be helpful!

Cheers.

Hiya,

I have built a core-image-base image, and included the following lines to my conf/local.conf file:

This works just fine, now. I can deploy and run Qt Widgets and Qt Quick applications via SSH on the target!

------------------

The two applications I tested successfully were built with qmake. However, if I try to deploy and run an application which is being built by CMake, it fails with the following errors:

Is there a way to also run and debug CMake-built applications using the Kit described in the Documentation via SSH?

Hi,

thank you for your quick response.

So, I followed the steps in the doc, and I successfully deployed two Qt applications on the board, one QtQUick and one QtWidgets application. The board runs on the fus-image-qt6 example image.

I indeed did install an additional library in the VM (QSerialPort), but it is not used for the example applications I try to test the remote debugging with.

However, when running it (either from the VM via SSH, or directly on the board), the program crashes with the error:

The same with the QtQuick app:

I guess, this is due to missing libraries on the board, which I assumed were present after building and deploying the fus-image-qt6 example image.

Hi,

I just came across this post, and I'd like to point out, that the commands also did not work for me (as it is still written in the Doc-File F&S Introduction to QT Debugging an Application v.1.11).

Instead, I did:

This seems to work fine (Qt and all Qt packages were built).

------

I'd kindly like to ask another question, related to the documentary pointed out earlier.

After building the toolkit and running the bash script in /tmp/deploy/sdk, the documentation guides me to do:

"After that you have to install the new root filesystem on your remote target system." (p. 10)

I am unsure, what it means. I have built a fus-image-qt6 earlier and flashed it to my efusa9r2q.

After running the bash script, the toolchain was installed to /opt/fus-imx-wayland/5.15-kirkstone. However, the images and build files in /tmp/deploy/images/fsimx6/ remained untouched.

Should I bitbake the qt6-image again, after installation of the toolchain?

Thanks!

Hello,

thanks for your answer.

I have sent you the patch file to support@fs-net.de.

Regarding your answer: I have been using the file efusa9dl.dtb first.

Using the efusa9r2dl.dtb was just a method to eliminate the error of using the wrong device tree.

Cheers,

Bjørn

Dear F&S Team,

I am working with the SINTF board and an eFus a9(r2) and a LVDS Display from a third party manufacturer. One of your collegues has provided me a patch, which patches the device tree once I build an image via Yocto to fit the display.

My issue is, that once I build an image including this patch, flash it to my board and run it, the display does not work. I have another eFus a9(r2) which has been prepared by F&S, which is working with the display. So, the display itself is ok.

These are the steps I followed:

To include the patch into the build, I have copied it to the location:

In the recipe fsimx6-Y2024.04/build/yocto-fus/sources/meta-fus/recipes-kernel/linux/linux-fus.bb, I have added the following lines at the bottom of the recipe:

I then started to build the image:

The build finished after some hours without errors. In the output directory fsimx6-Y2024.04/build/yocto-fus/build-fsimx6-fus-imx-wayland/tmp/deploy/images/fsimx6/, I can see, that the build has provided me with the zImage file, the rootfs.ubifs file, the .dts file and more (see attached image file).

Earlier I have succesfully deployed a UBoot bootloader and the image from fsimx6-Y2024.04/sdcard to my boad. My goal is, to simply replace the kernel image and the device tree on my board.

Thus, I have copied the files zImage and efusa9dl.dtb to /tftpboot directory, to perform an installation of these files to my board via TFTP. This worked fine, and after that, I could restart my board and the image loaded.

However, as a result, the display is not showing the typical weston desktop, as I would have expected. Using systemctl, I can see the weston service is running, restarting it did not do the trick.

I have also replaced the bootloader and the rootfs by the ones provided by the Yocto build (uboot.nb0; fus-image-std-fsimx6.ubifs).

I repeated everything by running:

I erased the NAND flash and re-deployed the UBoot bootloader. I tried installing the image, device tree and rootfs using a USB stick and the install.scr file.

The installation was as successful as the one using TFTP. However, the display remains dark.

I also installed the device tree file efusa9r2dl.dtb:

The installation worked, however, I do not think this is the right way, since

will expect the file efusa9dl.dtb and will throw an error, if it is not located in /tftpboot.

I have attached the output from PuTTY when I boot my board as a text file.

Looking at my steps, can you see any mistakes I did, for that the patch does not seem to actually patch the device tree to support my display?

Thank you very much in advance!

Best regards,

Bjørn Keohane