I would like to make an image with yocto for beaglebone black.
My project requires the uses of systemd.
I have made an image, I followed this tutorial: https://jumpnowtek.com/beaglebone/BeagleBone-Systems-with-Yocto.html
It works fine, but it uses sysVinit. Here is no problem (thanks jumpnowtek).
I searched how can use systemd and I have made some changes in the local.conf file.
The relevant part of my local.conf:
DISTRO_FEATURES = "systemd ext2 usbhost sysVinit ${DISTRO_FEATURES_LIBC}"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysVinit pulseaudio opengl"
PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
VIRTUAL-RUNTIME_init_manager = " systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
PREFERRED_VERSION_linux-stable = "4.9.%"
I didn't make any changes in the main part of config as you can find in the tutorial. I added some application to the distro only. (i.e. nginx, vim, gdb nothing special)
I could build with this local.conf it was succesfull, but the beaglebone can't boot.
The symptoms:
the 4 leds are blinking at the usb power, and the ethernet interface yellow/green led blinking also. But the HDMI doesn't have output, and a can't find the bone on the network. It look like the bone stag in the boot process. But I don't know, it's only tip.
Is anybody who met same issue?
The systemd required something, special settings?
I made missconfigure? Is it make errors at the compile time?
Thanks for answers.
EDIT: I close out hardware issue because I can use other image with same devices
Related
I've started to work with the Yocto project on a raspberry pi 3 and therefore followed the instructions in this guide.
It adds the dropbear ssh server for remote access
EXTRA_IMAGE_FEATURES_append = " ssh-server-dropbear"
After the creation of the image I checked the image manifest and it seems like dropbear has been added.
dropbear aarch64 2019.78
But it seems like when I run the image the application is not really there. I'd expect something inside /etc/init.d/ but there are no dropbear artifacts.
Also, altough the python meta-layer should be added, the py/python command is unknown on the target.
Can someone tell me what exactly I'm missing?
You're not specifying why you believe dropbear is not part of the image, if it is present on EXTRA_IMAGE_FEATURES (and you even see it in the manifest) I don't see any reason why it wouldn't be there, perhaps you are looking for it in the wrong location?
If you can post an update with the actual error you are getting that would help.
python3 does not come from the meta-python layer, it is part of the core layer (meta), meta-python contains other python related recipes which extend python's functionality.
To install python3 on your image do:
IMAGE_INSTALL += "python3"
I am trying to create a fast booting yocto image running a kivy gui on a raspberry pi 2B.
My problem is that, as soon as I add x11 to the build, the raspberry pi does no longer display the console on the screen.
Detailed Problem Description
Usually, when I boot the image without x11 the screen shows
the rainbow screen
the boot console (raspberries with text below)
the boot screen (big raspberry with a progress bar below)
a terminal to log in and a normal terminal afterwards.
As soon as x11 is added to the system (IMAGE_FEATURES:append = " x11-base", see setup below), my screen shows a black screen after step 3.
(probably unrelated: the official raspberry pi 7'' touchscreens turns black after step 2 independently of x11 being in the image)
However, when I don't add x11, kivy gives me a "can't find a window provider" error (which makes sense).
Configuration and Build
I am using the newest poky (kirkstone) and the following additional layers:
meta-raspberrypi (for the bsp package)
meta-openembedded/meta-python (providing the python3-kivy layer)
The interesting part of my local.conf file looks as follows:
MACHINE ?= "raspberrypi2"
EXTRA_IMAGE_FEATURES += "ssh-server-openssh"
RASPBERRYPI_DISPLAY = "1"
IMAGE_INSTALL:append = " python3-kivy mtdev"
IMAGE_FEATURES:append = " x11-base"
All other files, except the belayers.conf, are unchanged.
I am then building the image with
bitbake rpi-test-image
There are no errors or warnings during this build.
Does somebody have an idea how to solve this? I would appreciate help/inputs on
How to fix the issue with x11
How to avoid using x11 while still being able to run kivy
My Unity Editor was showing a blank white screen when trying to start a project. Image here:
This is for the Karting Microgame. When it loads it only displays a blank screen. When clicking the play button there is sound but nothing showing on the screen. This issue also occurs for other Unity3D microgames. I suspect it is an error with the graphics setup or maybe a bug?
Technical details:
Dell G15 laptop
Ubuntu 20.04
Unity version 2020.3.21f1, installed via Unity Hub
NVIDIA Graphics Card (NVIDIA GeForce RTX 3060 GPU)
NVDIA Driver Version 470 (https://packages.ubuntu.com/focal/nvidia-driver-470)
I also have an Intel integrated graphics card on my machine. Tried switching to integrated graphics via the sudo prime-select intel command but it didn't work. Also tried installing Dell G15 graphics drivers from the Dell website but it seems like they only have Windows graphics drivers. Currently the screen is still blank.
Relevant links:
Unity forum discussion, have the exact same problem except for Ubuntu:
https://forum.unity.com/threads/uni...n-problem-might-know-the-real-problem.545441/
Dell graphics driver link, but seems to only have for Windows:
https://www.dell.com/support/home/en-us/product-support/product/g-series-15-5510-laptop/drivers
Tutorial on switching graphics cards. First tried updating my drivers via the ubuntu-drivers command from my existing 470 version to the recommended 510 version, but ran into an error saying my computer holds broken packages. Then tried switching to Intel integrated graphics card via the prime-select command but it caused my GUI to break (had to switch back to NVIDIA via the command line.)
https://www.linuxbabe.com/desktop-linux/switch-intel-nvidia-graphics-card-ubuntu
Any help would be appreciated.
Open windows in safe mode and try again also there might be other programs open that are causing the blank screen for example vpn could cause it
I need to share this!
Try this:
In your project, delete the Library folder. I found that CurrentLayout-default.dwlt in particular must be deleted, so you can try that first if your project is big and want to avoid long rebuilding times.
In ~/.config/unity3d/Preferences/Editor-5.x, delete the Layouts folder
In ~/.config/unity3d, delete the Browser folder
In ~/.config/unity3d, delete the Editor folder (there is one sub-folder per editor version but the serial number cannot be trivially matched with a human-readable version, so maybe just delete the whole folder)
Restart the project
I found 1, 2 & 3 to work in my case, and only 1+2 or 2+3 not to work. At least it should work when installing a new editor / re-installing an editor version. I also did 4 at some point so it may be needed for editor versions already installed. I did 2 at the beginning so not sure if required.
I am attempting to upload my written program for the STM32F411RE from my TrueStudio for STM32 IDE to the board itself. The board is connected via the mini USB b cable and the intent is to program it via SWD.
Setup
Atollic provides a nice tutorial on how to perform this programming via it's TrueStudio IDE and the ST-Link_CLI (Command Line Interface), as described in the document at this link. This requires the following steps, which I have followed and checked multiple times:
First and foremost the output (binary) file needs to be an intel .HEX and
not the TrueStudio .elf default. To change this go to Project properties -> c/c++ build -> settings -> tool settings tab -> other -> Output format
and tick the option 'Convert build output', ensure that the Intel Hex
option is selected in the dropdown.
To call the ST-Link_CLI from inside the IDE requires making an external
tools configuration. To make this config I go to Run -> External Tools ->
External Tools Configurations .... and create a new configuration, lets
call it ST-Link_CLI. For the Working Directory I specify the directory of my ST-LINK_CLI
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility)
whilst for the Location I specify this directory and the file name
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK
Utility\ST-LINK_CLI.exe).
Lastly, I add the following parameters to
identify the STM32 board, have it connect via SWD and under reset, whilst
telling it to upload the .HEX file built by TrueStudio
(-c ID=0 SWD UR LPM -P ${project_loc}\Debug\${project_name}.hex -v).
Output
When I then call this external tool configuration via the Run -> External Tools -> ST-Link_CLI link just created I get the output listed below:
STM32 ST-LINK CLI v3.4.0.0
STM32 ST-LINK Command Line Interface
ST-LINK SN: 066EFF525750877267092042
ST-LINK Firmware version: V2J33M25
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V
Connection mode: Connect Under Reset
Reset mode: Hardware reset
Debug in Low Power mode enabled
Device ID: 0x431
Device flash Size: 512 Kbytes
Device family: STM32F411xC/E
Loading file...
Unable to open file!
Clearly the ST-Link_CLI is succesfully called from inside the IDE, but it somehow cannot digest the .hex file (inside the debug folder) and upload it to the STM32 board.
Even flashing a completely new generated project from CubeMX and setting the options above (including setting it to a .hex file) will not let this toolchain upload it to the board.
Manual code flashing
I have been able to succesfully upload the .HEX file built by TrueStudio via manually uploading it to the STM32 Board with the use of the ST-Link GUI, so I do not think the problem is in the ST-Link itself. I cannot however debug it in this manner, since I need the TrueStudio IDE tools for that and thus need the external tool configuration to work succesfully.
Instead I suspect the issue lies with my own setup, where is somehow is missing a call or has an option set incorrectly. It could also be that the GUI and CLI clients operate in a completely different fashion allowing one to read and upload the file whilst the other cannot, but that seems unreasonable to me.
I am kind of at a loss here however, as I cannot seem to figure out why others can make this work via the provided Atollic documentation and mine is throwing up these errors.
You try to reinvent the wheel using the triangle.
Everything is configured in the TrueStudio:
Just in add the debug configuration and you are done.
What benefits would OpenOCD offer at this point
One essencial : debugging
given how much I have already learned about TrueStudio?
This knowledge (how to configure external tools etc) is rather useless in 99.9999% of circumstances. It is only the configuration of the Eclipse. Not too complex actually needed here.
In regards to my own code, I have not been able to get the ST-Link_CLI to work as an external tool the way I intended, [but I have been able to get the STCubeProgrammer (CLI) to work in the same respective manner as I was attempting to do with the ST-Link].(http://gotland.atollic.com/resources/applicationnotes/AN1801_cubeprogrammer_in_truestudio.pdf).
Seeing as I literally used the same procedure as before but instead specifying the location and executable for the STCubeProgrammer (rather than the ST-Link), I suspect the issue may indeed be the ST-Link CLI (connection to TrueStudio).
It now uploads successfully and immediately after boots me into the debug environment of TrueStudio :)
I simply commented "load" command in the startup script and debugging worked. I only had to load the hex using the st link first.
/# Load the program executable
#load <---//added "#"
I am using Petalinux, built with Yocto SDK. I want to automatically install my kernel module and make the devices available in /dev/*.
With KERNEL_MODULE_AUTOLOAD+="modulename" I can see the appropriate entries in /etc/modules-load.d/ as well as entries in /sys/class/misc/** , but not in /dev/*. Is there something I am missing?
Well, the structure of Yocto has nothing to do with the creation of device nodes. Either your driver does that for you (upon loading / probing), or you had some script that made them earlier. As long as your module has been loaded upon boot, you've got KERNEL_MODULE_AUTOLOAD correctly. If the module gets loaded, but you're not getting any device nodes automatically (and you got that before) you'll need to investigate what has changed in your system. (Versions of kernel and eg mdev/udev etc)