Wednesday, June 13, 2018

qemu serial device

I had massive trouble getting additional serial devices recognized by my kernel because for some very stupid reason (including me possibly being even stupider): the serial devices are attached as ISA devices by default. 

Yes, when you add the "-serial stdio" or something similar the serial device is on an ISA bus instead of the ultra-modern PCI. I have not verified this for myself but read here. Also I have verified that if I add the serial character device as a PCI device it magically is detected by the kernel.

As I am basing my kernel in multi_v7_defconfig, I cannot even find CONFIG_ISA in the menuconfig kernel configuration tool. I did not venture into manually adding it to the .config, as when the menuconfig does not show me love, i learned to be a gentleman. Also do not forget to add the serial driver, usable by QEMU, if you are building your own kernel .config. The relevant fragment is:


To run 'serial for tcp' but with a pci-serial I found this explanation.
 -chardev socket,host=,port=59715,id=hostserial      -device pci-serial,chardev=hostserial

Sunday, March 04, 2018

ENV{DEVTYPE} does not seem to match

For some reason even though udevadm reports DEVTYPE, no udev rule matches when I try to use ENV{DEVTYPE}. Used ID_TYPE instead. Example udevadm report

UDEV [16712.707352] add /devices/platform/soc/soc:usb3-0/12000000.dwc3/ (block) ACTION=add DEVLINKS=/dev/disk/by-id/usb-Lexar_USB_Flash_Drive_0FBC0FD4BECE8A47B3FE-0:0-part1 /dev/disk/by-partuuid/8ec91e13-01 /dev/disk/by-path/ /dev/disk/by-uuid/662e6fe9-a29c-4a12-bc51-4a13c58b57c4 DEVNAME=/dev/sda1 DEVPATH=/devices/platform/soc/soc:usb3-0/12000000.dwc3/ DEVTYPE=partition ID_BUS=usb ID_FS_TYPE=ext4 ID_FS_USAGE=filesystem ID_FS_UUID=662e6fe9-a29c-4a12-bc51-4a13c58b57c4 ID_FS_UUID_ENC=662e6fe9-a29c-4a12-bc51-4a13c58b57c4 ID_FS_VERSION=1.0 ID_INSTANCE=0:0 ID_MODEL=USB_Flash_Drive ID_MODEL_ENC=USB\x20Flash\x20Drive\x20 ID_MODEL_ID=a209 ID_PART_ENTRY_DISK=8:0fgf ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=2048 ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_SIZE=62535680 ID_PART_ENTRY_TYPE=0x83 ID_PART_ENTRY_UUID=8ec91e13-01 ID_PART_TABLE_TYPE=dos ID_PART_TABLE_UUID=8ec91e13 ID_PATH_TAG=platform-xhci-hcd_3_auto-usb-0_1_1_1_0-scsi-0_0_0_0 ID_REVISION=8.07 ID_SERIAL=Lexar_USB_Flash_Drive_0FBC0FD4BECE8A47B3FE-0:0 ID_SERIAL_SHORT=0FBC0FD4BECE8A47B3FE ID_TYPE=disk ID_USB_DRIVER=usb-storage ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_VENDOR=Lexar ID_VENDOR_ENC=Lexar\x20\x20\x20 ID_VENDOR_ID=05dc MAJOR=8 MINOR=1 PARTN=1 SEQNUM=44772 SUBSYSTEM=block USEC_INITIALIZED=712706913

Sunday, February 25, 2018

wic in yocto

As of the time of writing the manual of wic in the the Yocto Mega manual has a massive omission. It only explains how to use wic individually and does not talk about the IMAGE_FSTYPES = "wic". Because of this if you ran wic create you will get strange errors like.

Please make sure wic-tools have %s-native in its DEPENDS, bake it with 'bitbake wic-tools'

This message will not appear if you set IMAGE_FSTYPES = "wic", because the IMAGE_DEPENDS_wic already contains the above dependencies.

Also with the IMAGE_DEPENDS_wic_append_${MACHINE} you can deploy boot packages which wic could required to create the images.

PS: I hate blogger interface.

Edit: While grepping my poky I found that the included documentation refers to exactly what I wrote above. Well may be some googler will find it useful.

Wednesday, February 21, 2018

Nice trick to diagnose gcc search paths

Recently I needed to use a compiler as part of an sdk and needed to point it to the correct sysroot. For some reason the --sysroot flag did not work correctly. To inspect what was going on in gcc 'mind' a colleague told me about a "trick":

gcc -o  ./g.c -E  -P  -v -dD

Wednesday, October 04, 2017

External Source kernel modules install does not fail as it should

Another small post to serve for future memory that when you are building Linux Kernel modules from external tree source, the kernel build system behaves differently. Yesterday it happened that I lost a huge amount of time trying to understand why the installation of a module was not exiting with error, when I clearly saw errors in the logs. The reason is that this is on purpose. In the build scripts for kernel installation there is this hidden gem: Don't stop modules_install if we can't sign external modules. I have been warned.

Monday, August 28, 2017

ParseError not a BitBake file

This error occurred to me when I made a require or include with the path to the file inside " quotation marks. The error message of course just said that  

ERROR: ParseError in "conf/machine/include/": not a BitBake file

Solution: Remove the quotation marks around the file path in any require or include directives.

Tuesday, July 18, 2017

A script that pause/plays on lock/unlock Spotify

A script that pause/plays on lock/unlock

dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver',member='ActiveChanged'" | \
  while true; do
    read X
    echo $X
    if echo $X | grep "boolean true" &> /dev/null; then
        dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
    elif echo $X | grep "boolean false" &> /dev/null; then
        dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause