how linux kernel detects power over ethernet (PoE) - linux-kernel

I want to capture a signal in the kernel when it detects power over ethernet is connected.
I don't have gpios to do this business.
I am working on the atheros chipset based access point. It has Realtek RTL8363SB ethernet module. Is there any mechanism/interrupt/signal/api in kernel which detects from where it is getting power?
I have enabled CONFIG_POWER_SUPPLY while building kernel V 2.6.36
Thanks.

Related

Emulate I2C on QEMU Aarch64

I have read this post How to emulate an i2c device on QEMU x86? about a solution for configuring an I2C device for QEMU emulating x86_64.
I am trying to do the same thing for ARM. Currently I have a simple I2C user space program that is timing out because although QEMU lists an I2C device in /dev it has no actual method of simulating the device and returning ACK. I was curious if someone could provide more detail on how I might implement the solution from that post because I am not very experienced in that area and the answer is pretty sparse in detail.
I am wondering how peripheral devices, other than USB, like ones using CAN and SPI are emulated when using QEMU.
Devices are supported on a device-by-device basis. QEMU emulation of Zynq 7000 can emulate certain EEPROM and flash devices and read and write to them over the I2C bus. Device support is listed here. Xilinx QEMU peripheral device support: http://www.wiki.xilinx.com/QEMU+-+Zynq-7000
I assume that support for other machine types is also on a by device basis, and hopefully it is as well documented as Xilinx's QEMU machines' peripheral support.
The wiki provided has other pages which provide examples of adding peripheral devices to the device tree. When you specify the device tree at QEMU invocation, QEMU will read the device tree and will begin emulating devices for which it has support.

Is a terminal and USB Device or a USB Host

If I use Tera Term, to connect to a USB OTG port on a STM32 MCU, is Tera Term a USB Device or a USB Host.
The question arises as I presumably could configure the STM32 OTG port to be a USB Host CDC or a USB Device CDC.
It's possible that it doesn't matter what I configure the STM32 USB OTG port as, but it's possible that there may be a specific standard that defines what should be done.
If I use Tera Term, to connect to a USB OTG port on a STM32 MCU, is Tera Term a USB Device or a USB Host.
Neither.
Your computer is a USB host. The software running on your computer doesn't affect its role.

How to specify virtual Address for pl011 uart in linux kernel

I am a beginner in kernel porting. I am trying to port Linux kernel (version- 4.9.22) on Custom SoC (cpu = arm1176jzfs based) for custom evaluation Board. I am having ARM Prime cell pl011 UART in my SoC. And it is physically mapped to 0x5800_1000 address. While i am trying to use it as Debug UART, kernel is asking for its virtual Address. How should i configure this option.
i.e:
-> Kernel low-level debugging functions
-> kernel low-level debugging port (Kernel low-level debugging on via ARM Ltd PL01x Primecell UART)
(0x58001000) Physical base address of debug UART
(??) Virtual base address of debug UART
Thanks,
Vivek T.
If you have a debugger, then you can certainly debug why your kernel is not booting up.
You can watch this steps:
-In Kernel configuration, enable CONFIG_DEBUG_INFO (Kernel Hacking -> Compile-time checks and compiler options)
-Compile the kernel
-From the debugger software, load the symbols from the elf. The command varies from one debugger to another
-Find symbol "log_buf", and chose option to "Display memory as dump"
So I think the kernel logs stored in the buffer. Maybe it can help you :)
Standard UART addresses are:
Standard port addresses are:
COM1 0x3F8 (1016)
COM2 0x2F8 (760)
COM3 0x3E8 (1000)
COM4 0x2E8 (744)
Additional port addresses are:
COM5 0x3E0 (992)
COM6 0x2E0 (736)
COM7 0x338 (824)
COM8 0x238 (568)

NVMe PCIe Hard Disk on Freescale LS2080A not recognised

I have a Freescale LS2080 box for which I am developing a custom linux 4.1.8 kernel using the Freescale Yocto project.
I have an NVMe hard disk attached to the LS2080 via a PCIe card, but the disk is not recognised when I boot up the board with my custom linux kernel.
I plugged the same combination of NVMe disk and PCIe card into a linux 3.16.7 desktop PC and it was detected and mounted without problem.
When building the LS2080 kernel using the Yocto project, I have enabled the NVMe block device driver and I have verified that this module is present in the kernel when booting on the board.
The PCIe slot on the board is working fine because I have tried it with a PCIe Ethernet card and a PCIe SATA disk.
I suspect that I am missing something in the kernel configuration or device tree, but I'm not sure what. When I add the NVMe driver to the kernel using menuconfig, the NVMe driver dependencies are supposed to be resolved.
Can anyone provide insight into what I am missing?
First make sure that PCIe device is recognized using lspci.
If device is not shown in lspci list this is enumeration problem, to check the error use PCIe analyzers.
If the device is shown in the list then simply add the device vendor id and device ID to NVMe driver and recompile to load the driver for your device.

Use of xHCI driver and USB_STORAGE driver

I'm currently learning driver programming and am at very nascent stage. I'm unable to get the difference of use of xHCI, EHCI, or OHCI drivers and usb_storage.
When I plug my USB device (pen drive) and observe dmesg output, it says that my device is using the ehci driver, but my device stops working when I rmmod usb_storage.
There are many drivers for different kind of USB devices let it be mouse, keyboard, camera, etc.
As of now, I assume that the xHCI driver is for USB host and the other driver is for the device we connect to our USB host. Am I correct? If not, what is the explanation?
*HCI are specifications of USB hosts:
xHCI - for USB 3.0
EHCI - for USB 2.0
OHCI and UHCI - for USB 1.x
usb_storage is a upper level driver working on the USB host side, and it is responsible for communication only with USB storage devices, not keyboard, mouse, etc.
The USB is maintained in form of a stack and *hci drivers are the lowest level in that stack. usb-storage and other drivers are located on a higher level of this stack.

Resources