I have an iMX8M Mini SoM from Embedian on their carrier board. I want to use the latest Yocto Zeus build, kernel 5.4.24, which requires u-boot to be updated. I followed Embedian's instructions but I am still having issues. When I power on the board I do not get any output on the serial connection, SER3, and this connection is confirmed working from using the onboard u-boot version. Here are the steps I took:
Ran bitbake virtual/bootloader
Ran sudo dd if=u-boot.bin of=/dev/sdb bs=1024 seek=33
Shorted TEST#, pins 9 and 10 on the MISC jumper of the carrier board
Inserted the SD card and powered on
I verified that /dev/sdb is the correct device from lsblk and tried writing other files for if=<file name> as well. The instructions on their website say the boot loader file should be called imx-boot-<machine name>-sd.bin-flash_evk but this file does not exist under the ".../deploy/images/<name>" directory. By shorting TEST# the carrier board is suppose to boot from the SD card but I do not get any output from the serial connection.
Solution
Thank you to user #elcfd for the solution. For other users if imx-boot-<machine name>-sd.bin-flash_evk does not appear after running bitbake imx-boot then run bitbake -c cleanall virtual/bootlaoder and bitbake -c cleanall imx-boot. After that run the bitbake imx-boot command and the file will then appear.
On the NXP boards u-boot can be described as a "container" which holds several different binaries. Your Yocto command is only building u-boot and not the u-boot "container". The command you want to run is bitbake imx-boot and this will generate the boot-<machine name>-sd.bin-flash_evk file you are looking for.
Related
I built core-image-sato-dev and after this when I did
runqemu qemux86 core-image-sato-dev
I got
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - INFO - Continuing with the following parameters:
KERNEL: [/opt/yocto/thud_workspace/build/tmp/deploy/images/qemux86/bzImage--4.18.33+git0+865683fc87_1a564c76f4-r0-qemux86-20220121081907.bin]
MACHINE: [qemux86]
FSTYPE: [ext4]
ROOTFS: [/opt/yocto/thud_workspace/build/tmp/deploy/images/qemux86/core-image-sato-dev-qemux86.ext4]
CONFFILE: [/opt/yocto/thud_workspace/build/tmp/deploy/images/qemux86/core-image-sato-dev-qemux86.qemuboot.conf]
runqemu - INFO - Setting up tap interface under sudo
[sudo] password for yocto:
but only the first time
I don't know what password is this.
The second time I run this the password is not asked anymore
What is setting up tap interface??
[sudo] password for yocto:
I don't know what password is this. The second time I run this the password is not asked anymore
This message is from your OS, not from Yocto. The password is likely to be the login password for the yocto user in your OS.
Yocto is calling a sudo command, and so your OS prompts you to enter your sudo password. You only have to do this once, because your OS is probably remembering your sudo login for a short period of time.
What is setting up tap interface??
A TAP interface can be created within Linux's network stack, that acts like real network hardware on your PC, but each packet it receives can be sent to a userspace program (QEMU in this case) for processing. It can also transmit packets passed to it from that same userspace program.
When QEMU runs your Yocto image, it emulates a virtual hardware device. To emulate the network hardware on this virtual device, QEMU needs a way to get network packets from the real network (on your PC) into the QEMU software, so that they can be passed into the virtual device.
So, when QEMU starts to run your Yocto image, it creates a TAP interface on your PC which is then used to pipe network packets in and out of the virtual device it's emulating.
Creating TAP interfaces on Linux requires higher privileges, and so Yocto automatically runs QEMU as sudo. Otherwise, QEMU would fail with a permissions error.
I'm using buildroot to compile a minimalistic linux with a 4.19-rt kernel. It is supposed to run on a raspberry pi 3b (arm processor). Additionally I want to run it on a x86_64 linux computer and found qemu as an emulation solution for that.
Building linux and kernel and running it on the raspi works. It boots, I can login and use it.
To test qemu I followed this instruction [1]. A recent raspbian with 4.19 kernel is booting fine so qemu seems to be installed correctly.
sudo qemu-system-arm -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster -hda 2019-09-26-raspbian-buster-lite.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -dtb qemu-rpi-kernel/versatile-pb.dtb
Bringing 1. and 2. together fails. When I try to emulate any self build linux, qemu only shows a black screen and one CPU is using 100%.
I used the same sdcard.img that works on the real hardware. I also tried to recompile the whole system with a normal 4.19 kernel (without real time). And I tried to build a versatile system (make qemu_arm_versatile_defconfig && make). None of it works.
Command to start the emulation:
sudo qemu-system-arm -kernel zImage -drive format=raw,file=sdcard.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/mmcblk0p2 panic=1 rootfstype=ext4 rw" -serial stdio
My main problem is, that there is absolutly no useful output. The command outputs the following
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
audio: Failed to create voice `lm4549.out'
and opens a window for the graphics output (that does not show anything). The message also appears when emulating raspbian so it does not seem to be the reason.
When I run qemu with the prebuild raspbian but without the -dtb argument, I get a message like "Error: invalid dtb and unrecognized/unsupported machine ID". I would at least expect something like this with my self build code. But because there is no output I'm out of ideas what even to google for.
Does someone maybe have an idea what I'm doing wrong or how I get qemu to provide me any useful information on what went wrong?
[1] https://blog.agchapman.com/using-qemu-to-emulate-a-raspberry-pi/
The problem is that a kernel will only boot on a piece of Arm hardware if it is compiled for that hardware. Otherwise it will generally fail, usually by crashing before it is able to output anything useful.
In particular, the QEMU 'versatilepb' machine is completely different to the Raspberry Pi. Any working set of instructions that use that machine type are really running a kernel built to work with the versatilepb board and a raspi userspace/filesystem on top of that. You're trying to build a kernel that has support for only the raspi on a machine that isn't a raspi, which won't work.
It is possible to build a kernel that works on more than one piece of Arm hardware, if you compile in the support for both board types (all the device drivers for both, etc). If you want to go down that path, I would suggest looking at the differences between the kernel config for the kernel that works and your one, and add plausible looking missing things until you find out what is actually required.
Your attempt to boot on QEMU directly from sdcard.img will not work, because QEMU's versatilepb board model does not support direct boot from sdcard (this would require us to run some kind of BIOS/firmware image in the guest, which we don't have). For versatilepb you need to supply directly to QEMU the kernel, possibly an initrd, and definitely the correct dtb for the versatilepb.
You might instead try looking at QEMU's "raspi2" and "raspi3" board models, which really do model the hardware of Raspberry Pis. The disadvantages however are that these models are missing some features and are not very actively developed, so often newer kernels don't boot on them, and also since there is no USB controller model there is no way to get networking. (This is why most blog posts etc suggest using the 'versatilepb' -- userspace doesn't often really care about exactly what hardware it's running on, so unless you're trying to do kernel development you can just run a versatilepb kernel and take advantage of the features like networking that that QEMU model has.)
Advanced Linux Sound Architecture (ALSA) tries to open audio interface device . you must provide audio device in qemu . Because the kernel is compiled with ALSA audio driver and you have compiled sdl library in Buildroot.
I have built the linux system for my RPi3 using buildroot. It boots properly and I can access the wired connection properly. However, I am stuck with enabling the wlan.
Here is what I have done so far.
Built the filesystem using buildroot:
make raspberrypi3_defconfig
make
After booting linux successfully I followed this link to enable wlan.
As the author of the post mentions, I had to select some of the wireless related packages by running make linux-menuconfig. But when I did run it, these packages were already selected.
I then ran make menuconfig and selected wpa_supplicant and other packages.
Now, when I boot the RPi3, wlan0 is not listed when I run ifconfig -a. I googled it a bit and found that there should be folder named wlan0 under /sys/class/net/. But I can only find eth0 and lo
Kindly guide me on how to get the wlan working. dmesg log is posted here
If you are using Buildroot, make sure you have selected BR2_PACKAGE_RPI_WIFI_FIRMWARE.
Also you have to manual load the wifi kernel module:
# modprobe brcmfmac
After that, you can confirm wlan0 with
# ifconfig -a
You could also configure Buildroot to build udev as /dev management option, in this case, WiFi kernel module will be loaded automatically.
I am trying to configure LIRC to work with my Raspberry 2B and a circuit I build with a transistor and a IR transmitter as explained in this tutorial
After the installation of LIRC, I followed all the steps and I added these two lines in /etc/modules
lirc_dev
lirc_rpi gpio_out_pin=36
Then I typed this in /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
After rebooting, I added the configuration of my Samsung remote (BN59-00516A) to /etc/lirc/lircd.conf
Then I restarted LIRC again but when I run a command to send a IR frequency
irsend SEND_ONCE Samsung_BN59-00865A KEY_POWER
it complains with the following error:
irsend: could not connect to socket
irsend: No such file or directory
I am guessing this is a problem with my device socket, because in the hardware.conf file I set
DEVICE = "/dev/lirc0"
(just because the tutorial states it), but lirc0 file isn't within the folder.
I couldn't find any other question related to this problem and google didn't help me much either. Does anyone have any hint on this?
After googling a lot, I found out an update is needed to have everything working properly. In my case I did:
apt-get update, apt-get upgrade, rpi-update
Also, as pointed out in this other tutorial, depending on the Raspberry firmware, you might need to add this to /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=XX,gpio_out_pin=YY
Substitute X and Y for whatever pins you're using!
I had a similar problem and I solved it with this command:
sudo lircd --device /dev/lirc0
If you set the value of LIRCD_ARGS in /etc/lirc/hardware.conf to "--device /dev/lirc0", it should start lircd appropriately, when /etc/init.d/lirc is started at boot.
you need to run lircd. It will create two files (lircd and lircd.pid) at /var/run/lirc/:
lircd
I got the same error messages. But had all configurations done. The restart of the lirc daemon solved this issue by typing
$ sudo /etc/init.d/lirc restart
I think is useful to say that the gpio_in_pin=XX,gpio_out_pin=YY part of the /etc/modules can be double checked with
dmesg | grep lirc
which results in something like
[ 3.437499] lirc_dev: IR Remote Control driver registered, major 244
[ 5.472916] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.621156] lirc_rpi: auto-detected active high receiver on GPIO pin 22
[ 6.622515] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 6.622528] lirc_rpi: driver registered!
for /etc/modules containing
lirc_dev
lirc_rpi gpio_in_pin=23 gpio_out_pin=22
I have setup a Linux server to run veins/omnet++ simulations on it. The main reason I am doing this is to decrease simulation time. The server is running Ubuntu Server 14.04.3, OMNET++ 4.6, SUMO 0.22.0 and VEINS 4a2. After installing OMNET and SUMO, I changed to VEINS root directory and run ./configure and make MODE=release -j 32. This generated an executable veins-4a2 file that I tried to run as:
./veins-4a2 -u Cmdenv -f examples/veins/omnetpp.ini //since omnetpp.ini is under examples folder
But I got the following error:
Loading NED files from /home/simulator/veins-4a2/examples/veins: 1
<!> Error: NED type `RSUExampleScenario' could not be fully resolved, due to a missing base type or interface.
Before running the previous command I did another ssh into machine to run the command ./sumo-launchd.py -vv -c sumo.
My questions is what does the error refer to? And have I missed any steps during my installation/configuration? Am I doing the make step for veins properly?
For future reference: Specifying the NED Path, or have a look at NED source folder from project properties