Abstract

Content

Introduction 1. Relevance of the topic 2. Purpose and objectives of the study, planned results 3. Current state of the problem 3.1 Comparison of existing system utilities for working with the file system 4. Investigation of UEFI capabilities for working with disk devices, file systems and files 5. Investigation of UEFI graphics and video capabilities for the development of a graphical user interface Conclusions List of sources

Introduction

For solving specialized tasks of setting up hardware or operating systems, the capabilities of firmware are often significantly limited by the hardware manufacturer. Various specialized system utilities can be used to expand the capabilities of the firmware. For example, working with files and directories requires a file manager.

1. Relevance of the topic

The development of a file manager in the form of a UEFI application allows you to successfully solve tasks for managing files and directories on a device with a faulty operating system or completely without it. Thanks to the UEFI platform, this application will work successfully on any hardware platform. In some cases, even without recompiling the application [1].

2. Purpose and objectives of the study, planned results

The aim of the master's thesis is to research and develop a file manager system utility for working with the file system using the capabilities of the UEFI platform.

To achieve the set goals, you must complete the following tasks:

• analyze the current state of the problem;
• analyze and compare existing system utilities for working with the file system on the UEFI platform;
• explore the possibilities of UEFI to work with disk devices, file systems and files;
• explore UEFI's graphics and video capabilities to develop a graphical user interface;
• develop software, conduct testing, draw up documentation;
• draw conclusions about the results of the work.

3. Current state of the problem

Modern system utilities capable of functioning without an operating system are mainly implemented using the MS-DOS operating system. System utilities developed as MS-DOS applications have the following significant drawbacks: lack of cross-platform functionality, application operation in real processor mode, limited available RAM to 1 megabyte, only a console interface, single-tasking, lack of support for new hardware and lack of network support. Intel has announced that it will drop support for the CSM in 2020, which provides compatibility with legacy system utilities that do not support UEFI. As a result, the use of system utilities running as MS-DOS applications will become impossible [2].

The system utility for working with the file system must have basic capabilities when working with files. To accomplish this task, the utility must perform: reading the partition table from the disk, reading and writing files in the file system, basic file manipulations such as renaming, moving, etc. Consider the existing utility systems for working with the file system.

3.1 Comparison of existing system utilities for working with the file system

3.1.1 Volkov Commander

The Volkov Commander file manager, a clone of the Norton Commander file manager developed by Vsevolod Volkov, was released in 1994 and has all the basic features [3]. The utility was developed using assembly language. Works in the DOS operating system environment. It is shareware and closed source software.

3.1.2 Grub2 File Manager

A file manager in the form of a UEFI application used to load various images of distributions of operating systems. The utility's source code was first published in February 2020 and is distributed under the GPL-3.0 license. Has limited ability to work with files and directories  [4].

4. Investigation of UEFI capabilities for working with disk devices, file systems and files

File I/O is accessed using the EFI_FILE_PROTOCOL protocol to the supported file systems. It provides access to the contents of a file or directory, and is also a link to the location in the file system directory tree where the file is located [5]. With any file descriptor specified, other files can be opened relative to the location of that file, giving new descriptors.

Query for the file system log on the device retrieves the EFI_FILE_PROTOCOL log for the volume. This interface is used to open the root directory of the file system as needed. The program must close the file descriptor using the Close() function for the root directory and any other open file descriptors before exiting. As long as there are open files on the device, you should avoid using basic device protocols that are abstracted by the file system. For example, EFI_DISK_IO_PROTOCOL or EFI_BLOCK_IO_PROTOCOL protocols.

A file system driver can cache data related to an open file. The function is provided Flush(), which flushes all unwritten data for this file in the filesystem to physical carrier. If the underlying device can cache data, the filesystem should also report device for cleaning. Implementations should consider cases where there is pending asynchronous I/O when a call was received on a blocking protocol interface. In these cases, the pending I/O will be processed and completed before the blocking function is executed, so that the operations are executed in the order in which they were requested.

Working with files is performed using various functions. Functions like Open() and Close() do opening and closing a file. The Read(), Write() functions provide byte read and write operations. Also, the protocol has various auxiliary functions that simplify the work and interaction with files.

5. Researching UEFI Graphics and Video Capabilities for Development graphical user interface

System utilities with a graphical user interface are simpler and friendly to use. To take advantage of the graphics capabilities, UEFI provides software an abstraction to support any graphics hardware [6]. However, implementation specifics on other platforms are possible [7].

The EFI specification defines the UGA (Universal Graphic Adapter) protocol as a device-independent way of supporting graphics. UEFI did not contain UGA and replaced it with GOP (Graphics Output Protocol) with the explicit purpose of removing VGA (Video Graphics Array) hardware dependencies. UEFI version 2.1 defines Human Interface Infrastructure (HII) to control user input, localized strings, fonts and forms using HTML. it allows you to develop graphical interfaces for applications supplied with an embedded software. The earliest implementations of UEFI embedded firmware were console. Many UEFI implementations today have a graphical interface.

The EFI_GRAPHICS_OUTPUT_PROTOCOL protocol provides a basic abstraction for setting video modes and copying pixels to and from the graphics controller framebuffer. Line address is also displayed hardware frame buffer, so the software can write directly to video equipment.

The main graphics operation in EFI_GRAPHICS_OUTPUT_PROTOCOL is block or BLT transfer. The BLT operation allows you to read or write data to the video memory of the video adapter. BLT operation abstracts the hardware implementation of video adapters by providing the concept of a BLT software buffer.

The framebuffer represents a frame as an array of pixels. The position of each pixel on the screen is defined by its x and y coordinates. The x coordinate represents the scan line (horizontal line pixels on the display). The y coordinate represents the vertical line on the display. Top left corner the video display has coordinates (0, 0), the lower right corner of the display is represented by (width - 1, height - 1). An image of the Blt software buffer is shown in Figure 4.

The Blt program buffer is structured as an array of pixels. Pixel (0, 0) is the first element software buffer Blt. Buffer Blt can be thought of as a set of scan lines. Location pixel on the screen is converted to a Blt buffer element using the following formula: element index buffer BLT = y * width + x, where width is the width, x and y are the coordinates of the pixel on the screen [8].

Each entry in the Blt software buffer is a pixel, consisting of a 32-bit value. The color components of the pixels of the Blt buffer have the format PixelBlueGreenRedReserved8BitPerColor, which defined in the EFI_GRAPHICS_OUTPUT_BLT_PIXEL structure. According to this format, zero byte represents blue, the first byte is green, the second byte is blue, and the third is reserved. The byte values ??for the red, green, and blue components of a color are its intensity. it the color intensity value ranges from a minimum 0 to a maximum intensity of 255.

The protocol provides the following helper functions named QueryMode, SetMode, and Blt. QueryMode() - the function returns information about the available graphics mode, which supports graphics device and a set of active image output devices. SetMode() - the function sets the video device to the specified mode, specified by the parameter, and clears the visible parts of the output display by painting them black. Blt() - the function is used to perform the operation defined by the BltOperation parameter with the passed buffer Blt and screen. Table 1 describes all supported Blt operations.

The EFI_GRAPHICS_OUTPUT_PROTOCOL protocol provides these basic capabilities without using operating system graphics driver. Software that uses graphics in the environment modern operating systems, uses a video accelerator, bypassing the BIOS functions [9]. In the same time, programmer using UEFI firmware features to work with graphics, is deprived of such an opportunity. He must record in the video memory by means of the central processor, following the VESA BIOS Extension methodology, or call INT 10h to output each pixel [10].

Thanks to the advanced BLT or Block Transfer feature implemented under the Graphics Output Protocol, potentially makes it possible to use a video accelerator. Data block in system memory and intended to be transferred to video memory can be processed by the GPU, interacting with the RAM in the Bus Master mode. To make this possible, support Graphics Output Protocol must be adapted to the specific graphics architecture processor and integrated into the firmware, which is located in the video adapter. This situation makes legacy BIOS features are not required.

Conclusions

At this stage of the dissertation, an analysis and comparison of existing system utilities for working with the file system on the UEFI platform. The possibilities of UEFI for working with disk devices, file systems and files. Explored the possibilities of UEFI for working with graphics and video, to develop a graphical user interface of the developed application. It was decided to continue developing a system utility for working with the file system in the form of UEFI GUI applications.

List of sources