Hongmeng kernel source code analysis (root file system) | first hang to the file system on ` / '| 100 blogs analyze OpenHarmony source code | v66 01

A hundred blog series This article is:

v66.xx Hongmeng kernel source code analysis (root file system) | file system first attached to / | 51 .c .h .o

Relevant articles of the file system are:

FHS | file system Hierarchy Standard

  • stay Mount directory In order to be compatible with the differences of file systems, the kernel introduces the concept of directory tree. The directory tree is spliced by each file system like building blocks. Any file system can be connected only by mounting to a directory. The kernel abstracts a unified mounting interface, and each file system can implement these interfaces by itself Since the directory is so important, it needs to be managed in a standardized way, which is followed by Unix like FHS Hongmeng also follows the specifications

  • The file system Hierarchy Standard (FHS) defines the main directories and directory contents in the Linux operating system. FHS is maintained by the Linux foundation. The current version is version 3.0, which was released in 2015. The basic directories are as follows:

    / : Root directory
    /bin : Essential user command binaries (for use by all users)
    /dev : Devices and special files
    /etc : Host-specific system configuration
    /proc : Kernel and process information virtual filesystem
    /sbin : Essential system binaries
    /sys : Kernel and system information virtual filesystem
    /usr/include : Header files included by C programs
    /usr/src : Source code
    /var/spool/cron : cron and at jobs
    

What is the root file system

What is the root file system? There are many articles on the Internet, but they are basically a big copy. It is true to say that it is the first file system mount ed when the kernel is started, but I want to redefine this concept. The so-called root file system is the file system hung on the root directory / first The core is the root directory // The directory doesn't have to belong to the file system first, otherwise it's a question of egg or chicken first, so don't be masked. It's no different from other file systems, but it comes first, takes the pit / account, and the subsequent ones can only be hung on the directory below it, and finally form an overall directory tree

After understanding the above, it is easy to understand the following problems:

  • There can be many different file systems in a system. Who does the root file system only depends on who the kernel wants to do at the startup stage
  • File systems can exist on many media, such as hard disk (mmc), flash memory (flash), and memory (RAM) Each media has its most appropriate supporting file system. mmc is generally (fat,ext),flash includes (jffs2) and memory (proc,sys,tmpfs,ramfs)
  • The file system can be simple and complex. As long as it can implement the three types of interfaces defined by the kernel, it can be called the file system. Which three types of interfaces are:
    • Mount interface: mountops
    • Operation node interface: VnodeOps *vop
    • Operation interface: file_operations_vfs *fop, the bottom layer of this interface actually operates the data block pointed to by the inode
  • In any case, there must be a file system for mounting to / after the kernel starts The directory structure of hongmenggen file system is as follows:
    .
    ├── app
    ├── bin
    │   ├── init
    │   ├── shell
    │   └── tftp
    ├── data
    │   └── system
    │       └── param
    ├── etc
    ├── lib
    │   ├── libc++.so
    │   └── libc.so
    ├── system
    │   ├── external
    │   └── internal
    └── usr
        ├── bin
        └── lib
    

How did these data come from? For example: libc So this C library function needs to be used immediately after startup. It needs to be made externally and burned to the specified location of flash At the same time, note that the root file system made by Hongmeng does not have a / dev directory, which is in Equipment documents Detailed in

Root file system production process

With liteos_a kernel as an example, it provides a method to make the root file system:

turing@ubuntu:/home/openharmony/code-v1.1.1-LTS/kernel/liteos_a$ make help
-------------------------------------------------------
1.====make help:    get help infomation of make
2.====make:         make a debug version based the .config
3.====make debug:   make a debug version based the .config
4.====make release: make a release version for all platform
5.====make release PLATFORM=xxx:  make a release version only for platform xxx
6.====make rootfsdir: make a original rootfs dir
7.====make rootfs FSTYPE=***: make a original rootfs img
8.====make test: make the testsuits_app and put it into the rootfs dir
9.====make test_apps FSTYPE=***: make a rootfs img with the testsuits_app in it
xxx should be one of (hi3516cv300 hi3516ev200 hi3556av100/cortex-a53_aarch32 hi3559av100/cortex-a53_aarch64)
*** should be one of (jffs2)

The seventh item, make rootfs and fstype, supports JFFS2 and VFAT file format system

This article tracks what happens after you hit make rootfs FSTYPE=jffs2

see kernel/liteos_a/Makefile

#Execute make rootfs FSTYPE=jffs2, and start here
$(ROOTFS): $(ROOTFSDIR)	#ROOTFSDIR dependent
	$(HIDE)$(LITEOSTOPDIR)/tools/scripts/make_rootfs/rootfsimg.sh $(ROOTFS_DIR) $(FSTYPE)	#Make image file
	$(HIDE)cd $(ROOTFS_DIR)/.. && zip -r $(ROOTFS_ZIP) $(ROOTFS)	#Hit rootfs Zip package

unscramble

  • Compile the target file of the whole kernel

      $(LITEOS_TARGET): $(__LIBS) sysroot
          $(HIDE)touch $(LOSCFG_ENTRY_SRC)
          #Compile makefile s in subdirectories one by one
          $(HIDE)for dir in $(LITEOS_SUBDIRS); \
          do $(MAKE) -C $$dir all || exit 1; \
          done
          # Generate liteos map
          $(LD) $(LITEOS_LDFLAGS) $(LITEOS_TABLES_LDFLAGS) $(LITEOS_DYNLDFLAGS) -Map=$(OUT)/$@.map -o $(OUT)/$@ --start-group $(LITEOS_LIBDEP) --end-group
      #	$(SIZE) -t --common $(OUT)/lib/*.a >$(OUT)/$@.objsize
          $(OBJCOPY) -O binary $(OUT)/$@ $(LITEOS_TARGET_DIR)/$@.bin #Generate liteos Bin file
          $(OBJDUMP) -t $(OUT)/$@ |sort >$(OUT)/$@.sym.sorted	#Generate liteos sym. Sorted file
          $(OBJDUMP) -d $(OUT)/$@ >$(OUT)/$@.asm # Generate liteos ASM file
    
  • Compile using $(APPS) kernel/liteos_a/apps Apps in the directory, such as init, shell and TFTP, are also called apps built into the kernel,

    # Compiling multiple applications
      $(APPS): $(LITEOS_TARGET) sysroot #Liteos dependent_ TARGET , sysroot
          $(HIDE)$(MAKE) -C apps all	#Execute the all target of Makefile in the apps directory, - C represents entering the apps directory,
    
  • use tools/scripts/make_rootfs/rootfsdir.sh Create directories under the root system (/ bin, /app, /lib)

    #Create individual directories of the root file system
     mkdir -p ${ROOTFS_DIR}/bin ${ROOTFS_DIR}/lib ${ROOTFS_DIR}/usr/bin ${ROOTFS_DIR}/usr/lib ${ROOTFS_DIR}/etc \
     ${ROOTFS_DIR}/app ${ROOTFS_DIR}/data ${ROOTFS_DIR}/proc ${ROOTFS_DIR}/dev ${ROOTFS_DIR}/data/system ${ROOTFS_DIR}/data/system/param \
     ${ROOTFS_DIR}/system ${ROOTFS_DIR}/system/internal ${ROOTFS_DIR}/system/external ${OUT_DIR}/bin ${OUT_DIR}/libs
     if [ -d "${BIN_DIR}" ] && [ "$(ls -A "${BIN_DIR}")" != "" ]; then
         cp -f ${BIN_DIR}/* ${ROOTFS_DIR}/bin
         if [ -e ${BIN_DIR}/shell ] && [ "${BIN_DIR}/shell" != "${OUT_DIR}/bin/shell" ]; then
             cp -f ${BIN_DIR}/shell ${OUT_DIR}/bin/shell #Copy the shell to / bin of the root file system
         fi
         if [ -e ${BIN_DIR}/tftp ] && [ "${BIN_DIR}/tftp" != "${OUT_DIR}/bin/tftp" ]; then
             cp -f ${BIN_DIR}/tftp ${OUT_DIR}/bin/tftp   #Copy tftp to / bin of the root file system
         fi
     fi
     cp -f ${LIB_DIR}/* ${ROOTFS_DIR}/lib    #C / C + + Copy the so library to / lib of the root file system 
     cp -f ${LIB_DIR}/* ${OUT_DIR}/libs
    
  • Use prepare to create a musl directory and copy the c/c + + library to this directory

    prepare:	#Preparation, create a musl directory for copying C / C + + So Library
      $(HIDE)mkdir -p $(OUT)/musl
      ifeq ($(LOSCFG_COMPILER_CLANG_LLVM), y) #Using clang-9, Hongmeng compiles with this by default
          $(HIDE)cp -f $$($(CC) --target=$(LLVM_TARGET) --sysroot=$(SYSROOT_PATH) $(LITEOS_CFLAGS) -print-file-name=libc.so) $(OUT)/musl #Copy the C library to the musl directory
          $(HIDE)cp -f $$($(GPP) --target=$(LLVM_TARGET) --sysroot=$(SYSROOT_PATH) $(LITEOS_CXXFLAGS) -print-file-name=libc++.so) $(OUT)/musl #Copy the C + + library to the musl directory
      else
          $(HIDE)cp -f $(LITEOS_COMPILER_PATH)/target/usr/lib/libc.so $(OUT)/musl
          $(HIDE)cp -f $(LITEOS_COMPILER_PATH)/arm-linux-musleabi/lib/libstdc++.so.6 $(OUT)/musl
          $(HIDE)cp -f $(LITEOS_COMPILER_PATH)/arm-linux-musleabi/lib/libgcc_s.so.1 $(OUT)/musl
          $(STRIP) $(OUT)/musl/*
      endif
    
  • tools/scripts/make_rootfs/rootfsimg.sh Generate image file rootfs_jffs2.img, call mkfs JFFS2 to make the image of JFFS2 file format

      ROOTFS_IMG=${ROOTFS_DIR}"_"${FSTYPE}".img"
      JFFS2_TOOL=mkfs.jffs2 #Tool for making jffs2 image file under linux
      WIN_JFFS2_TOOL=mkfs.jffs2.exe #Tool for making jffs2 image file under windows
      chmod -R 755 ${ROOTFS_DIR}
      if [ -f "${ROOTFS_DIR}/bin/init" ]; then
          chmod 700 ${ROOTFS_DIR}/bin/init 2> /dev/null
      fi
      if [ -f "${ROOTFS_DIR}/bin/shell" ]; then
          chmod 700 ${ROOTFS_DIR}/bin/shell 2> /dev/null
      fi
    
      if [ "${FSTYPE}" = "jffs2" ]; then
          if [ "${system}" != "Linux" ] ; then
              tool_check ${WIN_JFFS2_TOOL}
              ${WIN_JFFS2_TOOL} -q -o ${ROOTFS_IMG} -d ${ROOTFS_DIR} --pagesize=4096
          else
              tool_check ${JFFS2_TOOL}
              ${JFFS2_TOOL} -q -o ${ROOTFS_IMG} -d ${ROOTFS_DIR} --pagesize=4096
          fi
      elif [ "${FSTYPE}" = "yaffs2" ]; then
          # to do 
      fi
    
  • Finally, use the zip command to package rootfs into rootfs Zip, so far the production process of hongmenggen system has been completed
    An out directory will be added as follows:

    turing@ubuntu:/home/openharmony/code-v1.1.1-LTS/kernel/liteos_a/out/hi3518ev300$ ls
    bin  lib  liteos  liteos.asm  liteos.bin  liteos.map  liteos.sym.sorted  musl  obj  rootfs  rootfs_jffs2.img  rootfs.zip
    
    • rootfs is the hongmenggen file system
    • rootfs_jffs2.img is an image file that can be burned to flash

Start process

The code for starting the root file system is listed here

STATIC UINT32 OsSystemInitTaskCreate(VOID)
{
    UINT32 taskID;
    TSK_INIT_PARAM_S sysTask;

    (VOID)memset_s(&sysTask, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S));
    sysTask.pfnTaskEntry = (TSK_ENTRY_FUNC)SystemInit;
    sysTask.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE;
    sysTask.pcName = "SystemInit";
    sysTask.usTaskPrio = LOSCFG_BASE_CORE_TSK_DEFAULT_PRIO;
    sysTask.uwResved = LOS_TASK_STATUS_DETACHED;
#if (LOSCFG_KERNEL_SMP == YES)
    sysTask.usCpuAffiMask = CPUID_TO_AFFI_MASK(ArchCurrCpuid());
#endif
    return LOS_TaskCreate(&taskID, &sysTask);
}

unscramble

  • First, the kernel opens a task called SystemInit to process the system initialization code. The task entry function is SystemInit
  • SystemInit calls MountPartitions layer by layer to mount partitions
    SystemInit(void)
      ...
      OsMountRootfs()
        AddPartitions //Register partition driver
        MountPartitions()
            #define ROOT_DEV_NAME          "/dev/spinorblk0"
            #define ROOT_DIR_NAME           "/"
            ret = mount(ROOT_DEV_NAME, ROOT_DIR_NAME, fsType, mountFlags, NULL);//
    
    stay Equipment documents The source of / dev/spinorblk0 will be described in detail. In short, the root file system is burned on the first partition of nor flash media device. The partition name / dev/spinorblk0 only represents a "virtual" device file name, behind which is a real file system Now hang it on / and the result is that the first partition of nor flash becomes the root file system

Hongmeng kernel source code analysis General catalogue

v08.xx Hongmeng kernel source code analysis (general directory) | analysis of one hundred blogs annotated with millions of Chinese characters | 51 .c .h .o

Annotation of millions of Chinese characters Analysis of 100 blogs

Millions of Chinese character annotations > > intensive reading of Hongmeng source code, Chinese annotation analysis, deep excavation of foundation engineering, permanent memory of brain, and synchronous updating of four code warehouses every day< gitee | github | csdn | coding >

100 blog Analysis > > story telling kernel, Q & a guide, life metaphor, tabular description, graphical display, and regular updates of mainstream websites< 51cto | csdn | harmony | osc >

Be careful not to get lost Code is life

Love is all the reasons and answers - turing

Original is not easy, welcome to reprint, but please indicate the source

Keywords: Linux Operating System kernel harmonyos

Added by dragin33 on Mon, 27 Dec 2021 17:11:45 +0200