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?
Related
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.
hi i have a fpga chip having cortex-m3 as hard-ip with it,i installed uclinux on cortex-m3 .
i wrote a c code which turns on 8 leds according to the number i give (it runs good on uclinux ) but now i want to give input number from c code on uclinux and transfer it to fpga ,then fpga will process on it and will glow the Leds,but i havn't find a way to do that(communication between uclinux and fpga).
for e.g. i can communicate with pendrive using uclinux cause i have the driver for it or i can write for any other device but how to show fpga circuit as device to uclinux,
one way i thought was as uclinux can access any address of cortex-m3 using pointers similarly i can do it for fpga ,but i don't understand how a digital circuit on fpga can have addresses.
I am looking for some tutorials where writing LKM for some specific device has been taught.I learned basic of writing LKM but wanted to see how to write LKM for some device(fpga device or Network device). I know for writing LKM for device one need to know characteristics of a device.
But what could be characteristics of an FPGA device or Network device and how access them through LKM.
So,can anyone let me know what all are required to write a LKM for device?
Specifically to start learning to write Linux kernel networking drivers,
the following 2 tutorials should get you started.
Simple network driver for Realtek 8139
Network driver for AT91SAM9263 from scratch
A friend of mine asked me this question in the class and I could not answer it. He asked:
Since we know kernel controls the physical hardware via device drivers. What if all this functionality is kept inside the device controller itself rather than kernel managing them. What would be the consequences of such scenario? Good or Bad?
I searched online for this question but could not get information about this scenario. May be I'm not googling in the right keyword.
You insight into this will help me getting clearing my concepts.
Please answer.
Thanks.
Your question seems to propose the elimination of the "device driver" by "keeping" "control (of) the physical hardware ... inside the device controller". The premise for this seems to be:
kernel controls the physical hardware via device drivers.
That description of a device driver is something similar to what I've seem for end-user comprehension rather than from a developer's perspective. The end-user is aware of the device, and it is the device driver that takes that abstraction and can control that device down to the specific control bits of each device port.
But a device driver is responsible for mundane housekeeping tasks such as:
maintaining device status and availability;
configuring the device for operation;
managing data flow, setting-up/tearing-down data transfers, copying data between user space and kernel space;
handling interrupts and exceptions.
These tasks are integral to a device driver. These tasks cannot be transferred out of the purview of the kernel driver to a peripheral device.
Sometimes the device driver can only try to manage the device, rather than fully control it, for example, a NIC driver during a packet flood.
There is simply no possibility that you can eliminate a device driver no matter how much of "all this functionality is kept inside the device controller itself". And there would still be control directives/commands issued from the device driver to the peripheral.
The hardware device in question should be a computer peripheral device, not an autonomous robot device. The device should be designed to operate with a computer. Whatever interface there is between processor and device should be suitable for the task. If the peripheral is made more "intelligent", then perhaps the CPU can be unburdened and a high-level command interface can replace low-level sub-operation directives. But only "some" functionality can be transferred to the peripheral, not "all".