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:

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
# CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_EXAR=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_OF_PLATFORM=y

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

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/xhci-hcd.3.auto/usb3/3-1/3-1.1/3-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 (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/platform-xhci-hcd.3.auto-usb-0:1.1:1.0-scsi-0:0:0:0-part1 /dev/disk/by-uuid/662e6fe9-a29c-4a12-bc51-4a13c58b57c4 DEVNAME=/dev/sda1 DEVPATH=/devices/platform/soc/soc:usb3-0/12000000.dwc3/xhci-hcd.3.auto/usb3/3-1/3-1.1/3-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 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=platform-xhci-hcd.3.auto-usb-0:1.1:1.0-scsi-0:0:0:0 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

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.

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