Serial Console logging

To debug boot-up issues we need to configure Serial port as console in Kernel . We can easily collect dmesg information with this.

Steps to enable Serial logging :

1) Make sure serial driver statically built with kernel image . If it built as a module , we can not get bootup logs as it will not loaded at that time. If it is built as modules , make sure module name is added to /etc/modules.conf. So that module will be loaded .

2) Need to add kernel boot parameters for enabling serial port as console

Edit /etc/default/grub file

Replace  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"  with

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS4,115200n8 debug ignore_loglevel"

close the file and execute "sudo update-grub".

Make sure target system UART is connected to other system and configure UART.

Reboot the system and observe the logs will be displayed in both test system and Other system.

console=tty0  =>  the kernel to continue using the standard console device. Boot messges will be dispayed on target system monitor.

console=ttyS4 => the kernel to also use the first serial device as a console. ttySn , n will be the serial port device available.  grep dmesg with "ttyS" to find available ports in your system.

115200n8 sets the serial speed to 115200 bits per second with no parity and 8 data bits per character. The other end of the serial line also must be configured to same settings.

debug ignore_loglevel allows you to see ALL kernel messages on the configured console.

drm.debug=14 => if we need to enable drm specifc logs other than all logs.

log_buf_len=16M => set the dmesg buffer size to get all required logs.

extern Vs EXPORT_SYMBOL ?

EXPORT_SYMBOL macro creates a new kernel symbol entry and puts it in a special section of the kernel image, in __ksymtab section. When modules are loaded dynamically, he loader resolves the symbols during run time by parsing the entries of this section.

For exporting a symbol , Function prototypes don't need to be written with extern. extern is assumed by the compiler.  Its use is as unnecessary as using auto to declare automatic/local variables in a block.
 
Extern can be used for non-static functions that are statically linked during compile time.

Why Serial Data Transmission Is Faster Than Parallel Data Transmission?

how serial data transmission can be faster than parallel data transmission ? But lets see what it means..

To be with basics , At a given frequency Parallel data transmission is better than Serial data transmission. With parallel transmission , for one clock cycle we can transfer 1 byte but only one bit with serial data transmission.

But we can not use parallel data transmission at high frequency. High frequency will cause data lost , data corruption and synchronization issue . So it may need to transmit the  data and finally data rate will be limited.

If we use high frequency for serial data transmission , we can achieve higher data rate because data will be transmitted at only one line . so there is no synchronization and stability issues.

This is the reason SATA AHCI interface makes faster than PATA.  In latest technology we use only SATA AHCI.

SATA can run at lower power compared to PATA due to no of pins are less.


So , latest serial data transmission  can be called it as High Speed Serial Data Transmission .

One more example is PCIe is faster than PCI.

PCIe is a high speed serial computer expansion bus.

IOMMU - I/O Memory Management Unit

IOMMU stands for I/O memory management Unit.  It connects a DMA capable I/O  bus to the system memory. It provides memory protection and address translations for I/O devices. This address translation is implemented in paging based. Some architectures allow interrupt remapping in a manner generally similar to address translation.

IOMMU is controlled by system rather than device. As control is with OS , faulty device can not corrupt memory and also provide memory protection.

IOMMU is transparent to devices and their drivers.

IOMMU is used to enhance virtualized I/O performance.

Large regions of memory can be allocated without the need to be contiguous in physical memory. IOMMU will take care of mapping contiguous virtual addresses to fragmented physical addresses.

For devices that do not support memory addresses long enough to address the entire physical memory, the device can still address the entire memory through the IOMMU. This avoids overhead associated with buffer copies ( bounce buffer) to and from the memory space the peripheral can address.

Virtualized guest operating systems can safely be granted direct access to hardware. (Device pass-through).

Guest Virtual Address -> Guest Physical Address -> System Physical Address.
Guest Physical address is same as System Virtual address.

Device pass-through : This is the ability to directly assign a physical device to a particular guest OS. The required address space translation is handled transparently. Ideally a device’ address space is the same as a guest’s physical address space; however, in the virtualized case this is hard to achieve without an IOMMU. IOMMU is designed in such a way to  remap Guest Virtual address to Device I/O address in guest operating system. It allows the Guest OS to direct access to Hardware to improve performance. If we do not use IOMMU , guest physical address needs to remap to host physical address using Host OS intervence but it will delay the process. So directly providing access to VM will improve the performance.

Remapping of interrupts: Usually sharing device interrupts among several guests is complicated to handle. IOMMU provides a basis to separate device interrupts that are already shared by different devices. It remaps a shared interrupt to an exclusive vector to ease up its delivery to a particular guest OS.

Disadvantages:
I/O page tables need some amount of physical memory.
I/O translation can not be avoided.

Note : i just try to put my understanding on Guest OS to Host OS interaction with IOMMU in my words. Thanks to google for all the information.