Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 81
Текст из файла (страница 81)
Code on the Flash device must be stored in separatepartitions from those used for data storage. Since the code partition is aread-only area, we don’t need a FAT format and we can use a simplerlinear layout, which is similar to the layout we use for the ROM filesystem.One approach we could take is to shadow the entire NAND codearea. However, this would use up a lot of RAM! Instead, we normallyshadow only a subset of the ROM components permanently, and loadthe remainder into RAM only when access to them is required.If you are porting Symbian OS to a new phone platform, you can choosewhich OS components are permanently shadowed when you specify the382THE FILE SERVERcontents of the ROM image.
At a minimum, this needs to include thekernel, kernel extensions, media drivers, file server, file systems andESTART. You can include additional components – obviously there is atrade-off between the speed gained by having a component permanentlyshadowed, against the amount of RAM this consumes. These permanentlyshadowed components are stored on the Flash device as a separate coreOS image. At startup, a core loader program, which is one of the programsused to boot the OS, permanently shadows this entire image in RAM. Thecore loader does this shadowing before even the standard Symbian OSbootstrap has run.The phone manufacturer can choose to have the entire core OS imagecompressed, to reduce the amount of Flash space this consumes.
Thecore loader has to detect whether this is the case and decompress theimage where necessary. However, the core OS image is loaded as asingle entity and so the core loader does not need the ability to interpretthe file system format within it.9.4.4.2 The ROFS imageThe remaining OS components, which are not included in the core OSimage, are only loaded into RAM when they are required.
The schemewe use loads entire executables and data files into RAM on demand, inmuch the same way as we load executables from a removable disk. Thisis not the same as a demand paging scheme, in which components areloaded at a finer granularity (that of a hardware page, usually 4 KB) andin which we would need a more proactive scheme to unload code fromRAM that we deem to be no longer in active use.The ROFS is the entity that reads these OS components from NANDFlash and interprets the linear format of this code area, which is knownas the ROFS image.The standard Symbian OS loader (which I discuss in Chapter 10, TheLoader ) copies entire executables and library files from the ROFS imageto RAM, using the file server and the ROFS to read them.
The ROFS imagealso contains data files, such as bitmap files. Clients of the file server issuerequests to read sections of these data files, and again the file server usesROFS to read them from NAND Flash memory. Individual executablefiles within the ROFS image may be compressed, and it is the job of thestandard loader to detect this, and decompress them at load time.ROFS uses the NAND media driver to read from the NAND device inthe same way as the FAT file system does. The NAND region allocatedfor the ROFS code image may contain bad blocks and again ROFS usesthe bad block manager in the media driver to interpret these.To improve performance, ROFS caches all its metadata (its directorytree and file entries) in RAM.
The ROFS file format places file UIDs inthe metadata, as well as at the start of the file itself. This means thatFILE SYSTEMS383these UIDs are permanently cached, avoiding the need to make short,inefficient reads from the Flash to retrieve them.ROFS also employs a small cache for the file data area.Figure 9.16 shows all the components needed to support code anddata storage on NAND Flash memory – including ROFS and the coreloader.9.4.4.3 Booting the OS from NAND FlashSince it is not possible to execute code directly from NAND Flashmemory, a phone using NAND Flash for code storage has to providehardware assistance so that the processor is able to begin fetching codeand can start to boot Symbian OS.
Many platforms include a hardwareboot loader. This is logic associated with the NAND device that includesa small RAM buffer, and it has the effect of making a small part of thestart of the NAND device become XIP.This XIP area is often very small, typically less than 1 KB, and may betoo small to contain the core loader program. Instead a smaller minibootprogram is normally the first code to execute, and its function is to locatethe core loader program’s image, copy it into RAM and then execute it.Although, as we’ve seen, the NAND manufacturing process leaves acertain number of faulty blocks distributed throughout the device, usuallythe manufacturer of the device will guarantee that the first block is good.If the core loader can be contained within this block, then the minibootprogram doesn’t have to deal with bad blocks at all.Next the core loader program executes.
Its function is to locate thecore OS image, copy it entirely into RAM and then find and execute thestandard Symbian OS bootstrap. The core loader has to handle existingbad blocks within the core OS image, but not the detection and handlingof new bad blocks. It may also have to decompress the core OS image.The miniboot program and the core loader do not have access to thenormal Symbian OS NAND media driver, and so they have to duplicatesome of its functionality.
If you are creating a new phone platform, youmust provide miniboot and core loader programs to suit your particularNAND hardware configuration. Symbian provides reference versions ofthese, which you can customize.You must program the following images into the NAND Flash memoryfor a phone to be able to boot from NAND Flash:• The miniboot program• The core loader program• The core OS image• The primary ROFS image (and possibly images for secondary ROFSpartitions)384THE FILE SERVER• A partition table providing information on the location of all theseimages.As well as these, phone manufactures will often also program a preformatted user data image into NAND Flash, so that this is available as soonas the device is first booted.Phone manufactures must produce tools to program this data into thephone’s NAND Flash memory.
Symbian provides a reference tool whichwe use on our standard hardware reference platforms, and which you canrefer to. This is the nandloader, NANDLOADER.EXE. When programmingNAND Flash, we include this tool in a normal text shell ROM image,which we program onto our platform’s NOR Flash memory. The platformboots from this image and runs the nandloader which allows the user toselect and program the various component images into the NAND Flash.These images can be included in the nandloader ROM image or suppliedseparately on a removable media card. Finally the user can restart theplatform, which this time boots from the images now programmed ontothe NAND Flash.9.4.5 The composite file systemThe composite file system is unlike any of the file systems I’ve describedso far.
Although it implements the file system API that I introduced inSection 9.4.1, it doesn’t directly use either the local media sub-systemor a file server extension, as a standard file system would. Instead, itinterfaces with a pair of child file systems. The composite file system isanother part of the scheme we use to support code storage on NANDFlash.Once the core loader has loaded the core OS into RAM, the standardROM file system (which is embedded into the file server) provides accessto its components in RAM.
The ROFS provides access to the rest of the OScomponents, which it copies from NAND Flash on demand. Normally,the file server would mount two different file systems on two separatedrives, but file server clients expect to find all the ROM components on asingle drive – the Z: drive. So we use the composite file system to combineboth file systems. This file system is a thin layer, which simply passesrequests from the file server to either (or both of) the ROM file system orthe ROFS.
The composite file system uses the concept of a primary andsecondary file system, where the primary file system is always accessedfirst. In this case, ROFS is the primary file system, since the majority offiles are located there.At system boot, the standard ROM file system is the only file systemthat is accessible until ESTART loads and mounts the other file systems.Before this, on a phone using NAND for code storage, only the coreOS components are available on the Z: drive. ESTART then loads theSUMMARY385composite file system, dismounts the standard ROM file system andmounts the composite file system on the Z: drive in its place.
At this pointthe entire ROM image becomes available on the Z: drive.Figure 9.16 shows the components required to support code anddata storage on NAND Flash, including the composite file system –ECOMP.FSY.File Server (EFILE.EXE)ROMFSC:Z:FAT File system(ELOCAL.FSY)Composite File system(ECOMP.FSY)ROFSNAND FTL(NANDFTL.FXT)ROFS(EROFS.FSY)Read()Write()Format()userkernelCORE OSRAMRead()Media DriverCore LoaderBad Block ManagerBad Block InterpreterHardware Interface LayerHardware Interface LayersoftwarehardwareUSER DATA AREAROFS IMAGECORE OS IMAGEMINIBOOT&CORE LOADERNANDFlashKEYS/W ComponentFigure 9.16NAND memory sectionRAM memoryThe components involved in supporting code and data storage on NAND Flash9.5 SummaryIn this chapter, I have described the F32 system architecture including abrief overview of the client API, followed by a more detailed description386THE FILE SERVERof the design of the file server.
Next I described the file systems ingeneral terms before looking in detail at the log Flash file system (LFFS),the FAT file system, the read-only file system (ROFS) and the compositefile system. In Chapter 10, The Loader, I will describe the loader server,which is also part of the F32 component.10The Loaderby Dennis May and Peter ScobieIt said, ‘‘Insert disk #3’’ but only two will fit!UnknownThe file server process contains a second server, the loader server, whosepurpose is to load executables (that is, DLLs and EXEs).
It runs in aseparate thread from the main file server and is implemented using theSymbian OS client-server framework.In this chapter I describe the process of loading executables and themanagement of executable code in Symbian OS. In Section 10.3, I showhow the loader server operates: how it handles client requests, how itinteracts with the file server and I introduce some of the kernel-sidecode management services. In Section 10.4, I describe kernel-side codemanagement in more detail.However, before any of this, we should start by examining the formatof the executable files that the loader has to handle.10.1 E32 image file formatThis is the Symbian OS executable file format. Symbian provides toolsto convert from standard object file formats into the E32 image format:you would use the PETRAN pre-processing tool to convert PE format files(as output by GCC98r2 for example).
Similarly, you would use ELFTRANto convert from the ELF format files produced by ARM’s RealViewcompiler.You can configure these conversion tools to produce compressedexecutable files and it is the responsibility of the loader to detect acompressed executable and decompress it on loading.E32 image files consist of up of nine sections, in the order specified asfollows:388THE LOADER1) The image headerThe E32ImageHeader. I describe this in Appendix 2, The E32ImageHeader.2) Code section – .textThis section contains the executable code.3) The constant data section – .rdataThis section contains constant (read-only) data.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
