at25 spi eeprom device tree - device

newb here. I have installed the at25 eeprom driver as a kernel module, but need a pointer to creating a device tree entry. I have a loaded and tested an SPI device tree overlay. Any help appreciated. TIA

Related

Enabling second UART in U-Boot

I am working on a project with SAMA5D3-xplained board with CortexA5 processor and embedded Linux. I would like to send and receive some data via UART during U-Boot is running and before a kernel is loaded to the RAM. I have no idea what I should do. Should I add the second UART to U-Boot device tree source file? Should I change something in a board configuration file? Do you have any ideas on what steps I should take to achieve my goal? Thank you in advance for any help.
EDIT
I would like to use UART from U-Boot C code, not from U-Boot commands. I need to communicate with one of a peripheral device before the kernel is loaded to the RAM.
I assume that you are using the upstream U-Boot from https://source.denx.de/u-boot/u-boot.git.
The device-tree arch/arm/dts/at91-sama5d3_xplained.dts already contains the definitions for six different uarts called serial0 - serial5. serial0 is set in the /chosen node as the standard serial connection. You should be able to see all six devices with the 'dm tree' command.
The currently used UART can be switched by setting the stdin and stdout environment variables.
If you do not want to switch these variables, because you still want output on the default UART you will have to access the device driver. Unfortunately drivers/serial/serial-uclass.c does not yet export functions for this. But _serial_putc(), __serial_getc(), and __serial_tstc() should give you an idea how this is done.

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.

Beaglebone Black: Interaction between Device Tree and Kernel Module

I am currently developing a SPI Kernel Module for my Beaglebone Black (Debian Wheezy 2015-11-12, Kernel version 3.8.13-bone79). My kernel module can access (request_mem_region() => ioremap()) registers from the AM3358 processor (read/write) to manipulate the registers, to change the settings of the SPI0.
On the other side is my device tree, which can manipulate the pins of the SPI0.
Unfortunately, I´ve got Problems:
If I load my Device Tree first, and then my Kernel Module I get an message that I haven´t got permission to load my kernel module.
If I load my Module first and then my Device tree, all pinmuxes are allright, but the CLK of SPI0 is killed. Furthermore if I remove my module and free my allocated Memory (Registers, iounmap() => release_mem_region()) I get a 'Trying to free nonexistent resource' message.
You see, I am struggeling to understand the interaction between Device Tree and Kernel Module...
I would be extremely grateful, if someone could "push" me in the right direction... ;)
All the best
Flo

In linux, what is difference between Open firmware device tree and flattened device tree

In linux, what is difference between Open firmware device tree and flattened device tree.
How to identify the linux kernel is using which Device tree OF DT or FDT.
From here:
Open Firmware is a firmware interface specification designed by Sun in the late 1980's, and ported to many architectures. It specifies a runtime OS client interface, an cross platform device interface (FCode), a user interface, and the Device Tree layout for describing the machine.
FDT is to Open Firmware what DSDT is to ACPI. The FDT reuses Open Firmware's established device tree layout. In fact, Linux PowerPC support uses the same codebase to support both Open Firmware and FDT platforms.
As you can see, Flattened Device Tree (FDT) is a part of Open Firmware. So basically "Open Firmware Device Tree" and "Flattened Device Tree" is the same thing.
Take a look at drivers/of/base.c. It was added back in 1996, but functions from it are used for nowadays ARM device tree. So FDT is just a part of OF. That's why all functions for device tree begin with of_ prefix.
If you need more details, next articles may be useful:
Open Firmware
Device Tree
From the same link posted above
I see that
Other names for Flattened Device Tree (FDT) are "binary blob" and ".dtb".
dtc (Device Tree Compiler) - converts between the human editable device tree source "dts" format and the compact device tree blob "dtb" representation usable by the kernel or assembler source. dtc is also a dtb decompiler.
And device tree is human readable source in the format .dts or .dtsi
Hope this is more clear and right.
thanks.

How to write from linux device driver to hard drive using DMA

I can transfer chunks of data from application to device driver but unable to write the interface from device driver to actual harddrive using DMA. Is there any sample code or pointer on this?
Would greatly appreciate your help,
If you've not seen it already, this is pretty informative. It's part of this.

Resources