I am using two motes. one has unicast sender program on it and one has uni-cast receiver program on it. Instead of connecting receiving mote with PC, I want to use batteries for mote power source and I want to save outputs of both motes on its mote memory. How can I save output(printf command outputs) of each mote in mote memory and retrieve later on after completion of experiments. Is there any method(built-in functions, commands or code snippet) available for this
P.S. I am using zolertia z1 motes
The straightforward way is to use the xmem interface. The function prototypes are declared in file xmem.h:
https://github.com/contiki-os/contiki/blob/master/core/dev/xmem.h
For Z1 there's a platform-specific implementation of xmem in platform's directory.
If you have never worked with flash memory before, note that the "rewrite" operation is typically not supported by the hardware. You need to erase a whole sector of the flash before you can write anything in that sector. Therefore, the typical usage pattern for dumping sensor data or logs is "write only at the end, never modify". When the current sector is full, erase the next one and write there, and so until the whole flash is full.
Contiki also the Coffee filesystem, which a higher level interface if you need one.
Related
I'm trying to integrate FATFS file system on Micron NAND SPI FLASH. I'm using the SPI peripheral of the STM32L486RG as interface.
I have developped a low level driver through which I'm able to read, write and erase data from different locations in the NAND memory.
I have then integrated my Low-level driver APIs under diskio.c file in order they could be used by fatfs APIs.
I have successfully formatted the memory through f_mkfs (I'm getting FR_OK with both f_mkfs and f_open APIs and when debugging the fs object is containing the FAT signature).
However, when I try to write buffer into the file that I have created using f_oprn , I get "FR_INT_ERR" .
I have debugged my code step by step and I found that my get_fat function returns (1) as result which means that an internal error has occurred .
Any idea what could be the issue ?
I guess you need to erase the memory's sector you mean to write in - even though you write per pages and not per entire sector - and that's why using FatFs becomes tricky in NAND Flash.
Since your purpose is to bound the logical drive to the entire physical drive, you need to use the option ( FM_SDF | FM_ANY ) for the parameter opt into the f_mkfs function to format the memory.
We are working on project where we need to do some image processing on FPGA. For that purpose we are using ZedBoard with linaro (Ubuntu Version) running on it.
What we have already done is we have stored the image in binary form pixel by pixel in DDR using python script on Processing System of Zedboard.
Now our task is to read the content of DDR memory, process it and send back the processed output to DDR Memory again. We are using vivado xilinx tool for FPGA part. We tried to use AXI-DMA with AXI-Interconnect to read and write data from DDR.
My question is, Do We need to use SDK and some sort of C coding to read and write DDR Memory on Programmable Logic side? As we want to make our module start reading the data from DDR with a control signal and then start actual processing of Image data. Once we read specific block of data, process it and store the result back to DDR memory on the fly. We are not sure which IP Block do we need in our block design for vivado. Also do we need Block Ram Memory at the end before sending the date to DDR.
Can anyone who already done this sort of project or have any knowledge ? Any help from your side will be appreciated !
Thanks
The zynq FPGA provide an AMBA AXI interconnect for that purpose.
This is the interconnect on the right.
I am wondering how a hypervisor using Intel's VMX / VT technology would simulate memory-mapped I/O (so that the guest could think it was performing memory mapped I/O againsta device).
I think the basic principle would be to set up the EPT page tables in such a way that the memory addresses in question would cause an EPT violation (i.e. VM exit) by setting them such that they cannot be read or written? However, the next question is how to process the VM exit. Such a VM-exit would fill out all the exit qualification reasons etc. including the guest-linear and guest-physical address etc. But what I am missing in these exit qualification fields is some field indicating - in case of a write instruction - the value that was attempted to be written and the size of the write. Likewise, for a read instruction it would be nice with some bit fields indicating the destination of the read, say a register or a memory location (in case of memory-to-memory string operations). This would make it very easy for the hypervisor to figure out what the guest was trying to do and then simulate the device behavior towards the guest.
But the trouble is, I can't find such fields among the exit qualifications. I can see an instruction pointer to where the faulting instruction is, so I could walk the page tables to read in the instruction and then decode it to understand the instruction, then simulate the I/O behavior. However, this requires the hypervisor to have a fairly complete picture of all x86 instructions, and be able to decode them. That seems to be quite a heavy burden on the hypervisor, and will also require it to stay current with later instruction additions. And the CPU should already have this information.
There's a chance that that I am missing these relevant fields because the documentation is quite extensive, but I have tried to search carefully but have not been able to find it. Maybe someone can point me in the right direction OR confirm that the hypervisor will need to contain an instruction decoder.
I believe most VMs decode the instruction. It's not actually that hard, and most VMs have software emulators to fallback on when the CPU VM extensions aren't available or up to the task. You don't need to handle every instruction, just those that can take memory operands, and you can probably ignore everything that isn't a 1, 2, or 4 byte memory operand since you're not likely to emulating device registers other than those sizes. (For memory mapped device buffers, like video memory, you don't want to be trapping every memory accesses because that's too slow, and so you'll have to take different approach.)
However, there is one way you can let the CPU do the work for you, but it's much slower then decoding the instruction itself and it's not entirely perfect. You can single step the instruction while temporarily mapping in a valid page of RAM. The VM exit will tell you the guest physical address access and whether it was a read or write. Unfortunately it doesn't reliably tell you whether it was read-modify-write instruction, those may just set the write flag, and with some device registers that can make a difference. It might be easier to copy the instruction (it can only be a most 15 bytes, but watch out for page boundaries) and execute it in the host, but that requires that you can map the page to same virtual address in the host as in the guest.
You could combine these techniques, decode the common instructions that are actually used to access memory mapped device registers, while using single stepping for the instructions you don't recognize.
Note that by choosing to write your own hypervisor you've put a heavy burden on yourself. Having to decode instructions in software is a pretty minor burden compared to the task of emulating an entire IBM PC compatible computer. The Intel virtualisation extensions aren't designed to make this easier, they're just designed to make it more efficient. It would be easier to write a pure software emulator that interpreted the instructions. Handling memory mapped I/O would be just a matter of dispatching the reads and writes to the correct function.
I don't know in details how VT-X works, but I think I see a flaw in your wishlist way it could work:
Remember that x86 is not a load/store machine. The load part of add [rdi], 2 doesn't have an architecturally-visible destination, so your proposed solution of telling the hypervisor where to find or put the data doesn't really work, unless there's some temporary location that isn't part of the guest's architectural state, used only for communication between the hypervisor and the VMX hardware.
To handle a read-modify-write instruction with a memory destination efficiently, the VM should do the whole thing with one VM exit. So you can't just provide separate load and store interfaces.
More importantly, handling atomic read-modify-writes is a special case. lock add [rdi], 2 can't just be done as a separate load and store.
I know there exists read-only values in many languages (final in Java const in C++ etc.) but does such a thing as "Write-Only" values exist? I've heard a variation of this in jokes, such as write-only code, but I'm wondering if this is actually a legitimate concept in computer science. To be honest, I can't see how it would be helpful in any situation, but I'm just wondering.
In unix shell scripting there is a concept of write only memory. But it's not part of any shell or scripting language, it's a device: /dev/null.
The write-only device /dev/null is used to discard output you don't want. Generally by allowing the caller to redirect stdout and/or stderr to it.
There are other write-only memory on a computer. One example is your sound card which on some (older) unix machines are mapped to /dev/audio or /dev/dsp. Writing values to it makes your speaker produce sound but reading from it gets you nothing.
At the lower level of the device drivers themselves, these hardware devices are often connected to a specific memory or I/O address (some CPU architectures don't have separate memory and I/O address - just a single address space shared by RAM and all other hardware). So in a real sense these memory locations are really write-only.
There were certainly some FPUs for PCs that used a somewhat weird setup, by existing as memory-mapped devices. To perform some operations, you would simply write the value you wanted to operate on, to a memory address indicating what operation you wanted performed, the value would then (eventually) be available at another address.
I don't know if you would define this, strictly, as "write-only memory", it is rather memory where (part of) the address is used as an opcode.
I know the definition
A character device driver is one that transfers data directly to and
from a user process.
But can some one explain this in a more intutive way? First of all there should be a device. What is the device in the above definition?
If you say it can be a file, then can we say file reading and putting the data on the console an example of character driver?
What exactly is a character driver ?
Device driver is Integration of two pieces of code. First piece of code is how the driver services are made available to the application.(user space)
Second piece of code is the hardware access part. Instructions to carry out physical operation on target hardware.
Based on first piece of code we have three models. Character model, Block model, Network model. we can say character driver, block driver, Network driver.
First piece of code is totally kernel specific. what Interface kernel provides to access the hardware. Implementing first piece of code on Linux,windows on other os may be different. we should know what inteface it offers to provide services to application .
In linux From user perspective everyhardware is a file. Why means at boot time all the hardware devices present are detected and added to device tree. Based on hardware corresponding device node gets created automatically in /dev directory. As mentioned above if it is char device---> character device node. Block device---> block device node gets created.
To write character driver. we create a device node in /dev directory , assigning a major no and application usually performing read/write operations on device file.
We implement driver operations and assign driver operations to file structure (fops) pointer.
Device file request received by VFS. VFS turns device file operations into your corresponding driver operations.
APP--->dev file----> fops--->driver---->device.
dev file ---> interface between application and driver.
driver interacts ----> device
You can refer http://lwn.net/images/pdf/LDD3/ch03.pdf.
According to my knowledge,
The device can be your own private structure or system object.
The driver is said to be a char driver because the data read and write is in byte range
If you are writing your char driver you can use char buffer or kfifo to read and write into the device.
you can create your device file in procfs,
and can read/write as u wish and this is accomplished though your char driver
I hope that my answer helps you
Think of device driver as abstraction of various hardware that the kernel has to deal with. The device driver knows the details of hardware it is communicating with. So the kernel reads and writes data as it would do with any other filesystem file.
If you can make some reading on Device Drivers, you will find out that the system calls of fopen, read, write, fclose are all mapped to driver specific function calls.
There is 2 types of drivers: block driver and char driver. The difference is that first one handles with blocks of data and second one receives/transmits data byte by byte.
Ok, for example you have a device and you want to talk to it, how to do it?
You have a driver, simply a number of functions, that will be called by the kernel at the right time. Driver itself can't do anything (neither send data, nor receive data), you need to say your driver what it should do. As you should know so far, you can't discretely communicate with a kernel from user space. There are some tricks that you can use. What you are talking about named as device file. Your driver generates a file for your device and when you write something to this file from user space, driver is notified that it is some information to handle, it takes this information and provide this data to write function, that will transmit data to your device(in this case byte by bite).
Hopefully, this what you wanted to know.