I want to read data from CAN bus and for that I am using MPC2515 (as a CAN Conroller) via SPI.
Working on Up Board 2 based on Ubilinux (Linux kernel version is 4.9.45), its architecture x86 doesn't use device-tree entries like ARM for example. So how can I define SPI device settings?
Related
I would like to undertake a low level approach to transferring data from an FPGA to the STM32MP1 processor, I'm currently using an FTDI USB device which is an extra IC consuming power on my battery power device.
I would initialise and read data from the QUADSPI peripheral on the STM32 in dual bank mode.
I have been reading into kernel modules to gain register level access however they all seem to stop at Hello World or best toggling GPIO pins. I can't find any solid documentation for what I'm trying to do.
What is the best way to initialise a peripheral that has no Linux driver written for it?
SR-IOV lets PCIe devices expose a single physical function and multiple virtual functions. How does the kernel detect that a device supports virtual functions? Is it a part of the PCIe configuration registers? Where in the kernel are devices tested for how many functions they export?
EDIT: I'm looking for a line of code (or a file) in the kernel source that inspects a PCIe device in order to determine how many virtual functions it exports. I'd also settle for a link to the appropriate standard that lays out what information a device needs to send to the host in order to report that it supports multiple virtual functions.
An SR-IOV capable device defines the SR-IOV Capability (extended capability ID 10h).
This is specified in chapter 9 of the PCI Express Base specification revision 4.0. I'm not sure whether you can find a free copy online; you may need to be a PCI-SIG member.
In the Linux kernel, look for PCI_EXT_CAP_ID_SRIOV and PCI_SRIOV_TOTAL_VF in drivers/pci/iov.c.
How to set AVR to emulate EEPROM over SPI?
I would like to boot my TI's Piccolo from Atmel AVR AR32UV3A0512 via SPI port.
Piccolo has a feature that allows it to boot through SPI connected EEPROM.
TI documentation specifies that if the SPI is connecting to device other than EEPROM, the device should emulate EEPROM.
Does anyone know what is needed to do to make AR32UV3A0512 emulate EEPROM?
Any hint or link towards proper documentation will be appreciated.
I have not found any useful information in AVR documentation.
You need to program your Atmel AVR so that it transfers code to the Piccolo's internal memory using the appropriate data transfer flow. The data transfer flow depends on the chosen emulation boot mode. Keep in mind that you are not restricted to SPI emulation boot mode. You can use any of the following:
SPI
I2C
SCI
Parallel GPIO
SPI boot mode will not necessarily be the easiest one to implement. Anyways, the whole rigamarole comes down to two steps:
Step 1 (easy step): Choose an emulation boot mode, and configure the Piccolo accordingly, as described in the Bootloader Modes section of this doc: http://www.ti.com/lit/ug/sprugo0b/sprugo0b.pdf
Step 2 (hard step): Depending on the emulation boot mode you chose in step 1, you will need to program your Atmel AVR microcontroller to follow the respective data transfer flow. For example, if you chose SPI mode, then you must program your Atmel AVR to follow the transfer flow described in the SPI_Boot Function section of the above doc.
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.
I was going through the logs after booting up the intel edison. I came accross the word. Is it the name of bios?Does it do some security verification like key matching/checking and all ?
Intel Edison board, more precisely Intel Tangier SoC, has a Minute IA (i486+, also known as Pentium ISA microarchitecture) based MCU (for example, Intel Quark D2000 SoC has it as far as I know) which is part of so called Platform Services Hub (PSH). PSH has own Page Cache (to keep RTOS and its applications), LAPIC. The peripheral, such as DMA and I2C, is shared with System Controller Unit (SCU). SCU actually controls PSH.
When system starts MCU boots first. Inside it is a Viper RTOS with some modifications, i.e. it has a library to support sensors.
There is no information available from Intel regarding use of open source RTOS, such as Zephyr, on PSH.