I am working on a raw/barebone embedded system, and I need to support some filesystem in it.
So I want to undestand the necessary interfaces between upper filesystem and lower block device.
Linux could be a reference, but its design is too complicated for an embedded system.
What I can think about is block_read() and block_write() interfaces which are called by filesystem to read/write data from/to block devices. Are they enough? And is there any other needed interface?
Thanks,
Most file systems targeted for embedded systems provide a porting interface that you need to change in-order to port the FS to your project.
The functions that you need to provide in the porting process are usually:
read from flash
write to flash
erase flash
lock flash
unlock flash
Once the porting is done the FS should be able to create and manipulate files.
Here are some open source file systems targeted for constrained systems:
FatFs
SPIFFS
littlefs
Related
On my ARM system (Tegra based), I'm running the mainline linux kernel. It uses the device tree system.
I have enabled a hardware driver for the General-Memory-Bus (part of the SoC) in the .dts file by setting its status="okay". Recompiled the dtb and booted the kernel. But no device (/dev/xx) appears.
The driver is compiled into the kernel and can be seen by
cat /lib/modules/$(uname -r)/modules.builtin
The command
cat /sys/firmware/devicetree/base/<path to device>/status
returns "okay".
Do I need to make some kind of "mknod"?
What else is nessesary?
The traditional UNIX "stream of bytes" device model is a pretty high-level abstraction of most modern hardware, and as such there are plenty of drivers which do not create /dev entries for the devices they control largely because they don't fit that model. Bus drivers in particular are very much a case of that - they exist, but only for the sake of discovering and allowing access to the devices behind them; there is no /dev/sata that lets you interact with the actual host controller, sending out raw commands on any old port regardless of what's connected or not; there is no /dev/usb that lets you attempt arbitrary transfers to arbitrary endpoints which may or may not exist.
Furthermore, your typical 'external interface' controller as in this case is orders of magnitude less complex than an interface like SATA or USB - the 'device' itself is often little more than a register block controlling some clocks and a chip-select multiplexer. Even if the driver did create something you could interact with directly, there's not exactly much you could do with it.
The correct way to proceed in this situation is to describe your FPGA device in the DT as a child of the GMI bus, accurately reflecting the hardware, no less, then develop your own driver for that. The bus driver itself just sits transparently in the middle. And if you do want a quick and dirty way to get started by just reading and writing bus addresses directly, well, it's behind a memory-mapped I/O region; that's exactly what /dev/mem exists for.
I'm in charge of choosing a file system for an embedded Linux device.
The device is a Freescale iMX6 running with a eMMC NAND flash memory and a kernel v3.10.17.
I plan to partition the Flash as decribed below:
Partition #1: kernel - not mounted
Partition #2: rootfs - mounted at "/" in read-only mode
Partition #3: userdata - mounted at "/home" in read-write mode
"/var" and "/tmp" directories will be mounted as tmpfs.
In some previous embedded linux projects, I used to use UBIFS on NAND flashes that were not eMMC NAND flash.
Since eMMC NAND flashes include a wear leveling feature, UBIFS should not be used with them as UBIFS' wear leveling feature may interfere with the one used by the eMMC NAND flashes.
I was planning to use ext2 or ext3 for the Partition #2 (rootfs) and ext3 for the Partition #3. I was wondering if ext3 is robust enough so my data won't get corrupted easily after a power failure of a hardreset reboot.
Does anyone have a strong backgroung with all of this and could help me to figure out what file system would be the best ?
Thanks.
I use ext4 file-system on an eMMC device that contains user data in read/write mode on an embedded-linux system.
The system shuts down by hard-reset several times a day for months now. have not witnessed problems with data consistency yet.
cramfs and squashfs are popular for read-only embedded filesystems, because they are highly compressed in storage.
For read-write filesystems, the "normal" ones you might find on a standard Linux desktop install work well (ext3, ext4, etc.). Read about them and pick one that has a balance of overhead and error-correction, depending on what you need for your device.
For the most part the popularity of these filesystems is independent of the hardware you're using as storage -- drivers are used to actually write to the hardware; the filesystem is an abstraction layer above this.
Your comment about ubifs being inappropriate since the driver already does wear-levelling sounds correct to me. UBIFS is weird in that way. Other filesystems are pretty storage-agnostic.
I would like to programmatically copy a section of a file on another file. Is there any Win32 API I could use without moving bytes thru my program? Or should I just read from the source file and write on the target?
I know how to do this by reading and writing chunks of bytes, I just wanted to avoid doing it myself if the OS already offers that.
What you're asking for can be achieved, bot not easily. Device drivers routinely transfer data without CPU involvement, but doing that requires kernel mode code. Basically, you would have to write a device driver. The benefits would have to be huge to justify the difficulties associated with developing, testing, and distributing a kernel mode driver. So unless you think there is huge benefit at stake here, I'm afraid that ReadFile/WriteFile are the best you can do.
I am building a small OS. For that i wanted to play audio. I can use ports,interrupts. I have no restrictions as i am building an OS itself.
So how can i play an audio file using a C program. Please remember that I cannot and don't want to use any ready made library or so.
If you're building your own OS, you also need to care about the physical details of your audio hardware.
Differences in hardware is why operating systems introduced the concept of the device driver.
If your audio hardware is sound blaster compatible, have a look here:
http://www.phatcode.net/res/243/files/sbhwpg.pdf
There's an archive of lots of hardware-near audio code here (various hardware platforms):
http://www.dcee.net/Files/Programm/Sound/
Here's a chapter on programming sound devices:
http://www.oreilly.de/catalog/multilinux/excerpt/ch14-01.htm
I have a board with ARM processor and micrium RTOS on it. I need to read/write files from the USB memory stick. For example standard function, which renames file is next -
int FS_Rename (const char * sExistingName,
const char * sNewName);
which path i need to write into sExistingName to point file on my USB memory stick?
It is not as simple are having the 'correct path'; The RTOS itself does not include either file-system or USB support, if you are using Micrium's file-system, you will still need USB mass storage device support to access such a device.
It would help if you revealed what ARM device you are using (or even what board if it is COTS); the ARM core itself does not define any particular peripheral set; that is decided by the chip vendor using the ARM core under license.
If the USB controller is on-chip, the micro-controller vendor may have example mass storage device code for free. However USB host or OTG stacks (as opposed to device stacks), which is what you need, are more complex and are seldom free and often expensive.
Moreover, your micro will require a host or OTG controller rather than a simpler and more common device controller. With a device controller, your target could be a mass storage device, but it could not access one.
[edit]
Micrium provide a USB host stack that is compatible with their file-system. If you are using their file system, that would be the path of least resistance, but you will still need host controller hardware on your target.