How to disable serial console(non-kernel) in u-boot - linux

I am building a Yocto image for Intel Edison.
One of the image's components is u-boot with an Edison-specific patch. By default, Edison's UART port is used for u-boot console. I want to disable this feature, but only on the serial interface(u-boot also listens on USB and that needs to stay).
My main concern is the "Press any key to stop autoboot" feature on the UART port. I need this port to connect an accessory that might send something during the boot process of the main device.
How do I approach this problem? Is there an environment variable for this, or do I need to modify the sources?
Thanks in advance!

I'm getting back to this issue almost a year later, now I've managed to find a proper solution.
The board I was working on had a reasonably new u-boot in its BSP. To disable the serial console I had to do the following:
Add the following defines to the board's config header(located in include/configs/board.h):
#define CONFIG_DISABLE_CONSOLE
#define CONFIG_SILENT_CONSOLE
#define CONFIG_SYS_DEVICE_NULLDEV
Check if your board has early_init_f enabled in the same file:
#define CONFIG_BOARD_EARLY_INIT_F 1
Find the arch file(Something like arch/x86/cpu/architecture/architecture.c) and add this call to its early_init_f function. It actually modifies board's global data variable to have these flags:
gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
My board did not have one, so I had to add the whole function
int board_early_init_f(void)
{
gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
return 0;
}
Example:
If you are looking for board_early_init_f of Orange Pi 4B it is in /build/cache/sources/u-boot/v2020.10/board/rockchip/evb_rk3399/evb-rk3399.c
That's it. Hope this helps someone else!
see also

Setting the u-boot environment variable bootdelay to -2 disables the ability for the UART to interrupt the boot process on U-Boot 2017.01 release. It appears that -1 is a special case.
See common/autoboot.c from your U-Boot source tree for details.
About U-Boot Environment Variables

There's no way to do this, without modifying the source (configuration) of U-Boot.
To disable the serial console in U-Boot, you need to reconfigure U-Boot. The documentation from the master branch of U-Boot: Readme.silent
According to that one, you need to set:
CONFIG_SILENT_CONSOLE
CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
CONFIG_SYS_DEVICE_NULLDEV
CONFIG_SILENT_U_BOOT_ONLY is also needed if you want only U-Boot to be silent.
You might also need to test with CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC and possibly adding silent 1 to CONFIG_EXTRA_ENV_SETTINGS.
== UPDATE ==
See the following options for a possible workaround:
CONFIG_ZERO_BOOTDELAY_CHECK
CONFIG_AUTOBOOT_KEYED
CONFIG_AUTOBOOT_KEYED_CTRLC
CONFIG_AUTOBOOT_PROMPT
CONFIG_AUTOBOOT_DELAY_STR
CONFIG_AUTOBOOT_STOP_STR
These options will at least give you a way of requiring a magic string to stop the boot. It might be enough to help you. See README.autoboot

As told by Kyle you can set the bootdelay u-boot environment variable to -2.
This can even be done from a booted system using the fw_setenv utility.
On my mender raspberry pi image this utility was preinstalled.
Using sudo fw_printenv bootdelay showed it was set to 2, i set it to -2 with sudo fw_setenv bootdelay -- -2 (note the -- before the value, so -2 is interpreted as the value, not an option).
In my case it was a similar issue than the OP, with a LoraWAN node on a raspberry pi connected over the serial port that interrupted the boot.
So
remove the serial device causing issue
set bootdelay either from the booted system or from the bootloader
shutdown and add the serial device back

Here is the video where it is explained step by step how to prevent U-boot console from interrupting autoboot and sending debug messages on UART on Raspberry Pi - it should work similarly for other boards, provided they use U-boot. You will however need to find the right config files for your board in u-boot source folder. I know links only answers are frowned upon, so here' s a quick breakdown of a solution:
Install the dependencies
sudo apt install git make gcc gcc-aarch64-linux-gnu bison flex
Git clone the official u-boot repository. Alternatively you can git clone my fork of repository, where I already have the necessary changes for silent autoboot - but if you need the latest version, then you need to clone the official repository and make changes yourself.
git clone --depth 1 git://git.denx.de/u-boot.git
cd u-boot
Find your board config files - they depend on the model, e.g. rpi_3_defconfig for Raspberry Pi 3, rpi_4_defconfig for Raspberry Pi 4 and so on. Add the following lines to the end of the file
CONFIG_BOOTDELAY=-2
CONFIG_SILENT_CONSOLE=y
CONFIG_SYS_DEVICE_NULLDEV=y
CONFIG_SILENT_CONSOLE_UPDATE_ON_SET=y
CONFIG_SILENT_U_BOOT_ONLY=y
The first line removes the boot delay, so autoboot will not be interrupted by messages sent on UART interface. Next four lines enable silent boot, so U-boot will not send any messages on UART itself, because the messages might in turn confuse your device. One more little thing left, set silent boot environmental variable. Change the header file for your board (for raspberry pi it is include/configs/rpi.h ) by adding the following:
#define CONFIG_EXTRA_ENV_SETTINGS \
"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
"silent=1\0" \
ENV_DEVICE_SETTINGS \
ENV_DFU_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV
Now configure with
make rpi_3_defconfig
from repository main folder And build with
make CROSS_COMPILE=aarch64-linux-gnu-
When the build process finishes you will have a u-boot.bin file, which you need to rename (uboot_rpi_3.bin for Raspberry Pi 3) and copy to Raspberry Pi SD card at /boot/firmware/. Now you Raspberry Pi will not be disturbed by any messages on UART during boot. The UART functionality after boot will not be affected.
Relevant docs: https://gitlab.denx.de/u-boot/u-boot/blob/HEAD/doc/README.autoboot https://gitlab.denx.de/u-boot/u-boot/blob/HEAD/doc/README.silent https://wiki.ubuntu.com/ARM/RaspberryPi

Related

xen hvm : no console

I am trying to run opnsense as xen domU.
My host is debian 11 and xen boots as dom0 with this configuration :
dom0_mem=1G,max:1G dom0_max_vcpus=1
I am trying to boot on opnsense from iso with this file :
builder = "hvm"
name = "router"
memory = 1024
vcpus = 2
serial='pty'
sdl=0
vnc=0
disk = [ 'phy:/dev/sda3,sda,w'
, '/opt/iso/OPNsense-23.1-OpenSSL-dvd-amd64.iso,raw,xvdc,devtype=cdrom,r'
]
boot='cd'
-> xl create -c opnsense.cfg
The domU seems to boot (disk and CPU activity) but the console stays empty.
I tried to access to console with "xl console router" but the command returns :
"xenconcole: Could not lock /var/lock/xenconsole.14: Resource temporary unavailable."
Is there a special configuration for console in hvm mode ?
Thanks for help
Does opnsense actually support a serial console automatically in its installer iso image?
You may want to double check, just to make sure serial console actually works in your environment, with an ordinary Linux distribution install iso image if there is serial output.
The posted domU.cfg looks correct to me, it works in my non-Debian, non-OPNsense environment.

Raspberry I2C unbind/bin module doesn't work

i have a problem with binding modules to my RPI.
I have two DS2482 1Wire Master IC on my I2C Bus.
The first one on address 0x18 is working fine.
I'm using the DS2482 Kernel Module.
Initialising was done with this commands:
sudo modprobe ds2482
echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-1/new_device
The second Master has the address 0x19 and is also on I2C Bus 1.
Also he is listet in sys/bus/i2c/devices/i2c-1/
I figured out, that the second one was bindung to a lis331dlh module, so i unbind it an removed the module with:
echo 1-0019 > /sys/bus/i2c/drivers/lis331dlh/unbind
rmmod lis331dlh
But if i cat /sys/bus/i2c/devices/i2c-1/1-0019/modalias i get the lis331dlh back although i removed the module.
The main problem is, that i cannot bind 0x19 to the DS2482 driver:
https://i.stack.imgur.com/fVkyS.png
Does anybody have a solution?

Shell script seems to skip over commands while executing

I'm trying to create a process where, on detecting my smart watch connecting to it, my Raspberry Pi (4b 2GB) would automatically download new podcast episodes then transfer them to my watch. I have managed to create a udev rule to execute a shell script on detection, but it seems to skip the most vital commands (upodder and mtp-sendfile)? Code below:
#!/usr/bin/env sh
PATH=$PATH:/home/pi/.local/bin:/home/pi/.vscode-server/bin/485c41f9460bdb830c4da12c102daff275415b53/bin:/home/pi/.local/bin:/home/pi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
echo "Watch connected at $(date)" >>/tmp/scripts.log
# Download new podcasts
/home/pi/.local/bin/upodder
# Transfer podcasts
/usr/bin/mtp-sendfile ~/Downloads/podcasts/WFH_Beckham_Sweden_and_Bango.mp3 /Podcasts
echo "Upodder should've run by now">>/tmp/scripts.log
I know that the file runs because /tmp/scripts.log is created and updated, but the podcasts aren't downloaded or transferred. upodder is a linux podcast downloader and mtp-tools is a way to transfer files through MTP. It's pretty clear that the issue is with these two commands but I can't seem to find the solution anywhere. Thanks in advance.
edit: Iruvar suggestion has helped but now I get the error:
Unable to determine user's home directory, MTPZ disabled.
Device 0 (VID=091e and PID=4c05) is UNKNOWN in libmtp v1.1.16.
Please report this VID/PID and the device model to the libmtp development team
~/Downloads/podcasts/WFH_Beckham_Sweden_and_Bango.mp3: stat: No such file or directory
Seems the issue is with the home directory.

Emulate Sound Card ALSA snd-dummy (Docker - Kernel Rebuild - ALSA snd-dummy)

I am using a docker image which does not have the ALSA's snd-dummy module available. I need to emulate a sound card. I do not need (or want) to listen to audio.
Based on the many searches I have done I am rather certain that I want to use ALSA's snd-dummy module for emulating a sound card, which is essentially /dev/null.
Looking over the guide for ALSA Matrix:Module-dummy, it states that if "modinfo soundcore" returns that you have this module, then you don't need to recompile your kernel.
In my instance, I do NOT have "soundcore" or "sound" available. I gather that this means I have to recompile the kernel. Recompiling the kernel of a docker image is a new concept to me. Docker is a new concept to me.
In sort, I need to install ALSA's snd-dummy module onto a Linux docker image, which does NOT have soundcore/sound compiled into the kernel.
Docker Image:
https://github.com/fcwu/docker-ubuntu-vnc-desktop
ALSA Matrix snd-dummy:
https://www.alsa-project.org/main/index.php/Matrix:Module-dummy
Is this a potential solution for me?:
https://github.com/torvalds/linux/blob/master/sound/drivers/dummy.c
Edit:
When replacing ~/.asoundrc to the following and running "alsactl restore" I get the following output. Also, my host machine's volume is affected.
# .asoundrc
pcm.dummy {
type hw
card 0
}
ctl.dummy {
type hw
card 0
}
$ alsactl restore
alsactl: load_state:1683: Cannot open /var/lib/alsa/asound.state for
reading: No such file or directory Found hardware: "HDA-Intel"
"Realtek ALC269VB" "HDA:10ec0269,10280446,00100100
HDA:80862805,80860101,00100000" "0x1028" "0x0446" Hardware is
initialized using a generic method Found hardware: "Dummy" "Dummy
Mixer" "" "" "" Hardware is initialized using a generic method
I think the solution would be to mount the sound device into docker, the problem here that you must use privileged:
docker run -v /dev/snd:/dev/snd --privileged myImage ...
UPDATE
you may also insert kernel module snd-aloop and specify 2 as the index of sound loop device on your host:
sudo modprobe snd-aloop index=2
docker run -it --rm -p 6080:80 --device /dev/snd -e ALSADEV=hw:2,0 dorowu/ubuntu-desktop-lxde-vnc

PRU won't initialize for hcsr-04 ultrasonic sensor (Beaglebone black)

In order to use the hcsr-04 ultrasonic sensor using BBB's PRU, I have tried this git :
https://github.com/HudsonWerks/Range-Sensor-PRU
I get the error "the PRU failed to open", when I try to start "rangepru".
Doing some research, I feel like that is because my PRU is not initialized and that I should do : "echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.8/slots" to correct it.
But with the recent debian versions (4.x), the cape manager changed and I found the file "slots" at:
/sys/devices/platform/bone_capemgr/slots ; BUT, there is no way to open, modify it :
- using "nano" I get "slots.swp Permission denied"
- and by typing the correct echo command (modified from the one above) : I get : "write error: No such file or directory"
Best regards,
Elrise
You are probably missing a suitable device tree driver.
Try to follow the instructions on:
https://github.com/luigif/hcsr04
related to the compilation and installation of the driver.
If you have a proper development environment, executing make install should do everything for you.

Resources