aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorvetch <vetch97@gmail.com>2020-01-18 11:59:41 +0100
committervetch <vetch97@gmail.com>2020-01-18 11:59:41 +0100
commite7d6c04f0c0e2e3cbaa03a1026679e6b2d614cab (patch)
treea6af765cf5d3984a6db563e77fca30618b7f8972
parent6a2ab0ca2871c8fb92ba02d75b153b42f2c119f5 (diff)
downloadrpi-MMU-example-e7d6c04f0c0e2e3cbaa03a1026679e6b2d614cab.tar.gz
rpi-MMU-example-e7d6c04f0c0e2e3cbaa03a1026679e6b2d614cab.zip
Ramfs to md
-rw-r--r--Ramfs-explained.txt15
1 files changed, 11 insertions, 4 deletions
diff --git a/Ramfs-explained.txt b/Ramfs-explained.txt
index da70cb5..85d5ae5 100644
--- a/Ramfs-explained.txt
+++ b/Ramfs-explained.txt
@@ -1,19 +1,26 @@
+#Ramfs
+
A simple ram file system has been introduced to avoid having to embed too many files in the kernel in the future.
-The ram filesystem is created on the development machine and then embedded into the kernel. Kernel can then parse the ramfs and access files, that have been put in it.
+The ram filesystem is created on the development machine and then embedded into the kernel. Kernel can then parse the ramfs and access files in it.
Ramfs contains a mapping from file's name to it's size and contents. Directories, file permissions, etc. as well as writing to filesystem are not supported.
Currently this is used to access the code of PL0 test program by the kernel, which it then copies to the appropriate memory location. In case more user mode programs are later written, they can all be added to ramfs to enable the kernel to access them easily.
-Specification
+## Specification
When ramfs is accessed in memory, it MUST be aligned to a multiple of 4.
+
The filesystem itself consists of blocks of data, each containing one file. Blocks of data in the ramfs come one after another, with the requirement, that each block starts at a 4-aligned offset/address. If a block doesn't end at a 4-aligned address, there shall be up to 3 null-bytes of padding after it, so that the next block is properly aligned.
+
Each block start with a C (null-terminated) string with the name of the file it contains. At the first 4-aligned offset after the string, file size is stored on 4 bytes in little endian. Null-bytes are used for padding between file name and file size if necessary. Immediately after the file size reside file contents, that take exactly the amount of bytes specified in file size.
As obvious from the specification, files bigger than 4GB are not supported, which is not a problem in the case of this project.
-Implementations
+## Implementations
+
Creation of ramfs is done by the makefs program (src/host/makefs.c). The program accepts file names as command line arguments, creates a ramfs containing all those files and writes it to stdout. As makefs is a very simple tool (just as our ramfs is a simple format), it puts files in ramfs under the names it got on the command line. No stripping or normalizing of path is performed. In case of errors (i.e. io errors) makefs prints information to stderr and exits.
-Parsing/Reading of ramfs is done by a kernel driver (src/arm/PL1/kernel/ramfs.c). The driver allows for finding a file in ramfs by name. File size and pointers to file name string and file contents are returned through a structure from function find_file.
+
+Parsing/reading of ramfs is done by a kernel driver (src/arm/PL1/kernel/ramfs.c). The driver allows for finding a file in ramfs by name. File size and pointers to file name string and file contents are returned through a structure from function find_file.
+
As ramfs is embedded in kernel image, it is easily accessible to kernel code. The alignment of ramfs to a multiple of 4 is assured in kernel's linker script (src/arm/PL1/kernel/kernel_stage2.ld).