CN109614156B - Method, device and system for supporting driving of starting type external equipment - Google Patents
Method, device and system for supporting driving of starting type external equipment Download PDFInfo
- Publication number
- CN109614156B CN109614156B CN201811599440.8A CN201811599440A CN109614156B CN 109614156 B CN109614156 B CN 109614156B CN 201811599440 A CN201811599440 A CN 201811599440A CN 109614156 B CN109614156 B CN 109614156B
- Authority
- CN
- China
- Prior art keywords
- operating system
- uefi
- peripheral
- support module
- linux
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
Abstract
A method is provided for extending UEFI firmware to support the driving of boot-type external devices. The method comprises the following steps: running the extended UEFI firmware in response to loading the target operating system; booting a peripheral support module to support driving of a boot-class external device that cannot be directly driven by UEFI firmware, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which extended UEFI firmware is to be loaded; and loading a target operating system through the peripheral device support module after the boot-type external device is driven, wherein the peripheral device support module is obtained by: starting kexec and device mapper characteristics in a Linux-based micro operating system; introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism; the driver required for starting the external device is added into the micro operating system based on the Linux.
Description
Technical Field
The present disclosure relates to a technology of a driver of an external device, and in particular, to a method, an apparatus, and a system for extending UEFI (Unified Extensible Firmware Interface) Firmware to support booting a driver of a class external device.
Background
An ARM (Advanced RISC Machines) processor has the advantages of low power consumption, low cost, high integration and the like, and is widely applied to the field of mobile terminals, however, in the field of servers, an ARM server is still in an initial stage.
Currently, because the support of the startup class device on the AARCH64 architecture of the ARM server is not enough, for example, a certain type of network card is required to be used and PXE (Pre-boot Execution Environment) startup is completed on the card, but the network card may not provide support for AARCH64, so that the selection of the server manufacturer for the startup class device is limited.
ARM server vendors have now attempted to collaborate with their business partners to push external device vendors' support for AARCH64, which inevitably comes with additional development time and economic cost, and before ARM server ecology matures, external device vendors lack motivation, which in turn limits ARM server ecology development. In addition, experimental attempts are also made inside the Linaro organization, and the intention is to directly run UEFI driving of x86 edition by introducing qemux 86 virtual machine into UEFI firmware, but the method is tedious and complicated, and currently, the method can only reach the level of driving VGA (Video Graphics Array) display type external devices, and cannot provide support for starting type external devices.
Therefore, there is a need for a method of the AARCH64 architecture that is simple to operate and enables boot-like peripherals to support ARM servers.
Disclosure of Invention
The present disclosure provides methods, apparatus, and systems for extending UEFI firmware to support the driving of boot-type external devices. The method utilizes the extensive support of the Linux on the external equipment, uses the Linux as a module to introduce the AARCH64UEFI firmware, indirectly expands the support of the firmware on the external equipment, and simultaneously does not influence the support of the firmware on the Windows operating system.
In a first aspect of the disclosure, a method is provided for extending UEFI firmware to support driving of boot-type external devices. The method comprises the following steps: running the extended UEFI firmware in response to loading the target operating system; booting a peripheral support module to support driving of a boot-type external device that the UEFI firmware cannot directly drive, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which the extended UEFI firmware is to be loaded; and loading the target operating system through the peripheral device support module after the boot-type external device is driven. Wherein the peripheral device support module is obtained by: starting kexec and device mapper characteristics in a Linux-based micro operating system; introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism; the driver required for starting the external device is added into the micro operating system based on the Linux.
Further in combination with the first aspect, wherein loading the target operating system through the peripheral support module includes loading the target operating system through a Kexec launcher of a petitboost component of the Linux-based mini operating system.
Further, with reference to the first aspect, the obtaining a peripheral device support module further includes: the init flow is customized to automatically launch the client and server programs of the petitboost and the system components that depend on it.
In addition, in combination with the first aspect, introducing the udev and petitboost components in the Linux-based micro operating system includes increasing support of the petitboost component to UEFI firmware, so that the petitboost component utilizes runtime service (runtime service) provided by UEFI, thereby completing the function of the launcher, and providing implementation of the petitboost component of the AARCH64 platform, in compliance with a platform support framework of petitboost.
In addition, with reference to the first aspect, the method further includes adding, to the extended UEFI firmware, an identification of a peripheral support module, the peripheral support module being managed by the UEFI boot manager, where running the extended UEFI firmware includes: identifying whether a peripheral device support module exists; in the event that the presence of a peripheral support module is identified, a boot option defined in the UEFI specification is generated. Wherein the booting the peripheral device support module to support the driving of the boot-type external device includes: booting the peripheral support module if the start option is selected.
Further, in connection with the first aspect, the launch option is selected through a UEFI launch manager or through a UEFI shell interface.
In addition, with reference to the first aspect, the method further includes integrating a peripheral support module in the extended UEFI firmware, or selecting to load the target operating system from the peripheral support module through the UEFI shell interface without integrating the peripheral into the UEFI firmware.
In a second aspect of the disclosure, an apparatus for extending UEFI firmware to support driving of boot-type external devices is provided. The device includes: a processor; and a memory storing computer program instructions that, when executed by the processor, perform a method of driving to extend UEFI firmware to support boot-type external devices. The method comprises the following steps: running the extended UEFI firmware in response to loading the target operating system; booting a peripheral support module to support driving of a boot-type external device that the UEFI firmware cannot directly drive, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which the extended UEFI firmware is to be loaded; and loading the target operating system through the peripheral device support module after the boot-type external device is driven. Wherein the peripheral device support module is obtained by: starting kexec and device mapper characteristics in a Linux-based micro operating system; introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism; the driver required for starting the external device is added into the micro operating system based on the Linux.
Further, with reference to the second aspect, the obtaining a peripheral device support module further includes: the init flow is customized to automatically launch the client and server programs of the petitboost and the system components that depend on it.
Further in combination with the second aspect, wherein loading the target operating system through the peripheral support module comprises loading the target operating system through a Kexec launcher of a petitboot component of the Linux-based mini operating system.
Further, with reference to the second aspect, wherein introducing the udev and petitboost components in the Linux-based micro operating system includes adding support of the petitboost component to UEFI firmware, so that petitboost utilizes runtime services (runtime service) provided by UEFI, thereby completing the function of the launcher; and a platform support framework that follows Peitiboot, providing for implementation of the Petitboot component of the AARCH64 platform.
Further, in combination with the second aspect, the method further includes adding, in the extended UEFI firmware, an identification of a peripheral support module, the peripheral support module being managed by the UEFI boot manager. Wherein, the UEFI firmware of running extension includes: identifying whether a peripheral device support module exists; and in the case that the peripheral equipment supporting module is identified to exist, generating a starting option defined by UEFI specification. Wherein the booting the peripheral device support module to support the driving of the boot-type external device includes: booting the peripheral support module if the start option is selected.
Further, in connection with the second aspect, wherein the launch option is selected through the UEFI launch manager or through the UEFI shell interface.
In addition, with reference to the second aspect, the method further includes integrating a peripheral support module in the extended UEFI firmware, or selecting to load the target operating system from the peripheral support module through the UEFI shell interface without integrating the peripheral into the UEFI firmware.
In a third aspect of the disclosure, a system for extending UEFI firmware to support driving of boot-type external devices is provided. The system comprises: extended UEFI firmware and boot devices. The guiding device is configured to: running extended UEFI firmware; booting a peripheral support module to support a driven component of a boot-type external device that the UEFI firmware cannot directly drive, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which the extended UEFI firmware is to be loaded; and loading the target operating system through the peripheral device support module after the boot-type external device is driven. Wherein the peripheral device support module is obtained by: starting kexec and device mapper characteristics in a Linux-based micro operating system; introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism; the driver required for starting the external device is added into the micro operating system based on the Linux.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the claimed technology.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the embodiments of the present disclosure will be briefly described below with reference to the accompanying drawings. It is appreciated that the following drawings depict only certain embodiments of the disclosure and are therefore not to be considered limiting of its scope, for those skilled in the art will be able to derive additional related drawings therefrom without the benefit of the inventive faculty.
Fig. 1 is a schematic diagram schematically illustrating an application scenario according to an embodiment of the present disclosure;
FIG. 2 is a flow diagram schematically illustrating a method of extending UEFI firmware to support the driving of boot-class peripherals, in accordance with an embodiment of the present disclosure;
FIG. 3 is a flow diagram that schematically illustrates a method of extending UEFI firmware to support the driving of boot-class peripherals, in accordance with another embodiment of the present disclosure;
FIG. 4 is a flow chart further illustrating the method of introducing udev and petitbot components in the Linux-based mini operating system of FIGS. 2 and 3;
fig. 5 is a flow diagram schematically illustrating a method of adding an identified external device support module extended UEFI firmware in an extended UEFI firmware to support a drive of a boot-type external device according to an embodiment of the present disclosure;
FIG. 6 is a flow diagram schematically illustrating an implementation of a method of extending UEFI firmware to support the driving of boot-class peripherals, according to an embodiment of the present disclosure;
FIG. 7 is a schematic diagram that schematically illustrates selection of a peripheral support module by a UEFI boot manager, in accordance with an embodiment of the disclosure;
fig. 8 is a schematic diagram that schematically illustrates selecting a target operating system through a UEFI shell interface, in accordance with an embodiment of the present disclosure;
FIG. 9 is a block diagram that schematically illustrates an apparatus for extending UEFI firmware to support the driving of boot-up class peripherals, in accordance with an embodiment of the present disclosure;
fig. 10 is a block diagram that schematically illustrates a system that extends UEFI firmware to support the driving of boot-type external devices, in accordance with an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings, and it is to be understood that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. The components of the embodiments of the present disclosure, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present disclosure, presented in the figures, is not intended to limit the scope of the claimed disclosure, but is merely representative of selected embodiments of the disclosure. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the disclosure without making creative efforts, shall fall within the protection scope of the disclosure.
It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present disclosure, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.
Generally, UEFI firmware starts an operating system following the UEFI PI (Platform Initialization) standard, and the system goes through 7 stages from power-on to power-off: SEC (Security phase), PEI (Pre-EFI initialization), DXE (Driver Execution Environment), BDS (boot device selection), TSL (transfer System Load, operating System Pre-Load), RT (Runtime), and AL (disaster recovery) phases. When the BDS phase is run, one of the important tasks is to boot and load the target operating system by driving the boot external device. At least some of these boot-type peripherals are not directly drivable by the UEFI firmware, and are required to provide a drive corresponding to the UEFI so that the UEFI firmware can communicate with it via the drive. However, in the early stage of the current ARM server, many boot-class external devices only support UEFI drivers of version X86 and lack UEFI drivers supporting version AARCH 64. Therefore, the UEFI firmware cannot drive such external devices, and even load the target operating system through it.
In the face of such boot-type external devices that cannot be directly driven by UEFI firmware, the present disclosure utilizes the kexec mechanism of Linux to implement the driving thereof, which allows the system to directly boot a new kernel from the currently running kernel.
Fig. 1 is a schematic diagram schematically illustrating an application scenario according to an embodiment of the present disclosure.
Referring to fig. 1, a user intends to load a target operating system stored on a boot-type external device, but the external device does not provide a driver corresponding to extended UEFI. At this time, the extended UEFI firmware first starts a Peripheral Support Module (PSM), drives a boot-type external device that the UEFI firmware cannot directly drive, loads and boots a target operating system stored on the external device, and finally starts the target operating system.
It is noted that the target operating system is shown in fig. 1 as being stored on the boot-type external device for example only, but those skilled in the art will understand that the target operating system may not be stored on the boot-type external device, for example, when the boot-type external device is a network card, the target operating system may be remotely loaded from a website where the image of the target operating system is stored through a network protocol.
Fig. 2 is a flow diagram schematically illustrating a method of extending UEFI firmware to support driving of boot-type external devices according to an embodiment of the present disclosure.
Referring to fig. 2, a method of extending UEFI firmware to support driving of a boot-type external device according to an embodiment of the present disclosure includes: at step S22, the extended UEFI firmware is run in response to loading the target operating system. At step S23, the peripheral device support module is booted to support driving of boot-class external devices that the UEFI firmware cannot directly drive, wherein the peripheral device support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to be loaded by the extended UEFI firmware. In step S24, after the boot-type external device is driven, the target operating system is loaded through the peripheral device support module.
Therefore, the target operating system is started by driving the external device through the middle layer, namely the peripheral device support module, so that the problem that the UEFI firmware cannot drive the external device can be avoided. This approach is easier to operate, less costly in terms of economy and time, and does not adversely affect the development of other elements in the ARM server ecology, as compared to the approach of developing an external device in conjunction with an external device vendor to support UEFI firmware or changing the UEFI itself to drive the external device.
Among them, the peripheral device support module according to the embodiment of the present invention can be obtained by the following steps: in step S211, kexec and device mapper characteristics are turned on in the linux-based mini operating system. This step may be implemented by configuring the config file of the kernel. This enables the linux kernel included in the micro operating system to support kexec system calls to implement kernel switching operations, and enables the micro operating system to support a peripheral block device managed by a Logical Volume Manager (LVM) using an architecture provided by the device map that maps from a Logical device to a physical device. In step S212, petitboot components of udev and petitboot are introduced into the Linux-based mini operating system. Wherein the petitboost component is an initiator using the Linux kexec mechanism. In step S213, a driver required to boot the class external device is added to the Linux-based mini operating system.
Specifically, a root file system of the linux-based micro operating system can be made by means of Buildroot or yocoto, and comprises the steps of adding petitboost, kexec-tools, lvm, udev and other components in the root file system. The kexec-tools can be called by the petitboost, and then called to a Linux kernel in a Linux-based micro system, then the kernel is switched to the kernel of a target operating system due to the kexec system call, and the LVM can be used by the petitboost to drive the peripheral block device managed by the LVM (logical volume manager) by means of the device map characteristic provided by the kernel. In this way, when the peripheral device support module serving as the middle layer is started, the linux-based micro operating system is directly booted from the kernel currently running to the new kernel of the target operating system based on the kexec mechanism, so that a firmware link in the conventional boot process can be completely avoided, and the target operating system stored on the external device can be quickly and easily started.
It will be readily appreciated that the fully functional peripheral support module should be obtained prior to running the extended UEFI firmware to boot the peripheral support module after running the extended UEFI firmware.
Illustratively, loading the target operating system through the peripheral support module includes, but is not limited to, loading the target operating system through a Kexec launcher of a petitboost component of the Linux-based mini operating system.
Fig. 3 is a flow diagram schematically illustrating a method of extending UEFI firmware to support driving of boot-type external devices according to another embodiment of the present disclosure.
Referring to fig. 3, unlike fig. 2, the step of obtaining the peripheral device support module may further include step S214, customizing the init flow to automatically start the client and server programs of petitboost and the system components depending on the client and server programs. Specifically, the customized init flow can be implemented by the following method: configuring/etc/init.rc under a root file system by using an init system of the busybox, and finishing self-starting of a petitboot server program and a udev program at the/etc/init.d/adding script; and adding a udev rule under the etc/udev/rule.d/by utilizing the udev to directly start the graphical interface of the petitboost client without starting the interactive shell, thereby completing the self-starting of the client and server programs of the petitboost and the system components depending on the petitboost.
In this way, the starting process of the target operating system can be automated, namely, the target operating system is automatically started from the peripheral equipment support module selected in UEFI firmware until the client of petitboot appears on the terminal equipment without manual intervention.
It is noted that without this step, the peripheral support module can still function properly, but only manual intervention is required to assist the entire boot process during the boot process.
FIG. 4 is a flow chart further illustrating the process of introducing udev and petitbot components in the Linux-based mini operating system of FIGS. 2 and 3.
Referring to FIG. 4, FIG. 4 more specifically describes the steps of introducing the petitboost component of udev and petitboost in a Linux-based mini operating system: in step S2121, the petitboost component adds support to the UEFI firmware so that petitboost utilizes runtime services (runtime service) provided by the UEFI, thereby completing the function of the launcher. At step S2122, an implementation of the petitboost component of the AARCH64 platform is provided, following the platform support framework of petitboost.
Thus, the target operating System is loaded remotely from the local block device or through Network protocols such as FTP (File Transfer Protocol), SFTP (Secure File Transfer Protocol), TFTP (simple File Transfer Protocol), NFS (Network File System), HTTP (Hypertext Transfer Protocol), HTTPs (Hypertext Transfer Protocol Secure Protocol), etc., using petitboost, thereby implementing enumeration and loading of the target operating System by the peripheral support module. In addition, by adding the support of UEFI firmware by the Petitwood component, the Petitwood component can utilize runtime service (runtime service) provided by UEFI, thereby solving the problem that the existing Petitwood component is mostly used for Sony PlayStation3 and IBM OpenPower server and lacks the support of platforms except for Power and PowerPC.
Fig. 5 is a flow chart further illustrating the process of fig. 2 and 3 for running extended UEFI firmware in response to loading the target operating system.
Referring to fig. 5, step S22 in fig. 2 or 3 may further include: step S221, adding identification of a peripheral equipment support module in the expanded UEFI firmware, and managing the peripheral equipment support module by a UEFI starting manager; step S222, running the extended UEFI firmware and identifying whether a peripheral equipment support module exists; if the peripheral equipment support module is identified to exist, executing the step S223 to generate a starting option defined by UEFI specification; if the presence of the peripheral support module is not recognized, indicating that the addition of the peripheral support module in the extended UEFI firmware was unsuccessful, step S221 may be performed again until the presence of the peripheral support module is recognized in step S222.
In this way, by adding identification of the peripheral support module to the UEFI firmware, when the firmware runs to the BDS phase, the existing peripheral support module is identified, and the boot option of the peripheral support module is generated according to the boot option (boot option) defined in the UEFI specification. Moreover, the UEFI boot manager (boot manager) directly manages the boot mode, so that a user can know and control the boot process of the operating system more intuitively, and the boot mode of the target operating system can be selected conveniently.
Having described in detail the method of extending UEFI firmware to support the driving of boot-type external devices according to an embodiment of the present disclosure, the overall boot process of the method is described below with reference to fig. 6 and 7.
Fig. 6 is a flow chart schematically illustrating an implementation process of a method of extending UEFI firmware to support driving of boot-class external devices according to an embodiment of the present disclosure.
Referring to fig. 6, when the target system needs to be booted by the boot-type external device, the extended UEFI firmware is first run. As described previously, the firmware undergoes 7 boot phases in sequence, following the UEFI platform initialization standard, wherein the presence of the peripheral support module is recognized in the BDS phase and the boot options available for the user to select are generated. In the case where the option is selected, the process of booting the peripheral device support module is started to be executed. At this point, boot control is transferred to the peripheral support module. Since the peripheral support module has turned the kexec feature on, the petitboot component will perform the boot of the kexec mechanism. According to the configuration of the init flow in step S34, the client graphical interface process, the server process and the necessary support processes of the petitboost component are loaded and started. The server process scans a target operating system on the external equipment by using an interface provided by a driver of the starting type external equipment, transmits scanning information to the client graphical interface process, and then loads and starts the target operating system in a preset value or user interaction mode.
Thus, after the target operating system is successfully started, the extended UEFI firmware normally interacts with the target operating system through UEFI runtime services and ACPI, while the middle layer operating system peripheral module does not function any more, and the final result is as if the UEFI firmware directly booted the target operating system.
Fig. 7 is a schematic diagram schematically illustrating selection of a peripheral support module by a UEFI boot manager according to an embodiment of the present disclosure.
Referring to fig. 7, upon successful identification of the Peripheral device Support Module, a boot option for the Peripheral device Support Module is generated according to a boot option defined in the UEFI specification, which is displayed on an interface of the boot manager, such as "Peripheral Support Module" shown in fig. 7, and a user may manually select to boot a target operating system from the Peripheral device Support Module.
Therefore, the user can control the starting option more intuitively and conveniently. Next, in case the booting item of the peripheral device support module is selected, a booting process of the peripheral device support module will be started to support the driving of the boot-type external device.
Fig. 8 is a schematic diagram schematically illustrating selection of a target operating system through a UEFI shell interface according to an embodiment of the present disclosure.
Referring to fig. 8, when the boot-type external device is successfully driven, the shell interface displays one or more target operating systems stored on the external device, and as shown in fig. 8, the user may select to boot the "Ubuntu" operating system among the target operating systems. In this way, the user can store one or more target operating systems commonly used on the external device and flexibly boot one of them as needed.
Furthermore, a peripheral support device module according to an embodiment of the present disclosure may be integrated into the UEFI Firmware by being packaged into a UEFI FV (Firmware Volume). The launch item may be selected at this point via the launch manager or UEFI shell interface. It is noted that in some embodiments, the peripheral support device module may also be booted through, for example, a USB interface without being integrated into the UEFI firmware, and then selectively booted from the peripheral support module through the UEFI shell interface.
Fig. 9 is a block diagram schematically illustrating an apparatus for extending UEFI firmware to support driving of boot-type external devices according to an embodiment of the present disclosure.
The device includes: a processor 91, and a memory 92, storing computer program instructions that, when executed by the processor 91, perform a method of extending UEFI firmware to support the driving of boot-type external devices. The method comprises the following steps: running the extended UEFI firmware in response to loading the target operating system; booting a peripheral support module to support driving of a boot-type external device that the UEFI firmware cannot directly drive, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which the extended UEFI firmware is to be loaded; and loading the target operating system through the peripheral device support module after the boot-type external device is driven. Wherein the peripheral device support module is obtained by: starting kexec and device mapper characteristics in a Linux-based micro operating system; introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism; the driver required for starting the external device is added into the micro operating system based on the Linux.
In one embodiment, wherein loading the target operating system through the peripheral support module comprises: the target operating system is loaded through the Kexec launcher of the petitboost component of the Linux-based mini operating system.
In one embodiment, the step of obtaining a peripheral device support module further comprises: the init flow is customized to automatically launch the client and server programs of the petitboost and the system components that depend on it.
In one embodiment, wherein introducing udev and petitboot components in a Linux-based mini operating system comprises: adding the support of the Petitboot component to UEFI firmware, so that Petitboot utilizes runtime service (runtime service) provided by UEFI, thereby completing the function of the launcher; following the platform support framework of Peitiboot, implementations of the Petitboot component of the AARCH64 platform are provided. In one embodiment, wherein the method further comprises adding an identification of a peripheral support module in the extended UEFI firmware, the peripheral support module managed by the UEFI boot manager, wherein running the extended UEFI firmware comprises: identifying whether a peripheral device support module exists; in the case that the existence of the peripheral equipment support module is recognized, generating a starting option defined by UEFI specification; wherein the booting the peripheral device support module to support the driving of the boot-type external device includes: booting the peripheral support module if the start option is selected.
In one embodiment, the boot option is selected through a UEFI boot manager or through a UEFI shell interface.
In one embodiment, the method further comprises integrating the peripheral support module in the extended UEFI firmware or not integrating the peripheral into the UEFI firmware, and loading the target operating system from the peripheral support module through UEFI shell interface selection.
As described with reference to the above embodiments, by executing instructions stored on the memory 92 for performing a method of extending UEFI firmware to support driving of boot-type external devices by the processor 91, the external devices may be driven by the peripheral support module to boot the target operating system, thereby bypassing the problem of the UEFI firmware being unable to drive the external devices; the linux-based micro operating system is directly guided to a new kernel of a target operating system from a kernel which is currently running based on a kexec mechanism, so that a firmware link in a conventional guiding process can be completely avoided, and the target operating system can be quickly and easily started; wherein, the target operating system is loaded from the local block device or remotely through network protocols such as FTP, SFTP, TFTP, NFS, HTTP, HTTPS and the like by utilizing petitboost, so that the peripheral support module can realize enumeration and loading of the target operating system; the method comprises the steps that by adding support of a Petitboot component to UEFI firmware, the Petitboot component can utilize runtime service provided by UEFI, and the problem that the conventional Petitboot component is mostly used for Sony PlayStation3 and an IBM OpenPower server and lacks support of platforms except for Power and PowerPC can be solved; and the identification of the peripheral equipment support module is added in the UEFI firmware, and the UEFI boot manager directly manages the boot mode, so that a user can know and control the boot process of the operating system more intuitively and select the boot mode of the target operating system more conveniently.
Fig. 10 is a block diagram that schematically illustrates a system that extends UEFI firmware to support the driving of boot-type external devices, in accordance with an embodiment of the present disclosure.
The system comprises: extended UEFI firmware 101 and boot device 102. Wherein the boot device 102 is configured to run extended UEFI firmware; booting a peripheral support module to support a driven component of a boot-type external device that the UEFI firmware cannot directly drive, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which the extended UEFI firmware is to be loaded; and loading the target operating system through the peripheral device support module after the boot-type external device is driven. Wherein the peripheral device support module is obtained by: starting kexec and device mapper characteristics in a Linux-based micro operating system; introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism; the driver required for starting the external device is added into the micro operating system based on the Linux.
In one embodiment, wherein loading the target operating system through the peripheral support module comprises: the target operating system is loaded through the Kexec launcher of the petitboost component of the Linux-based mini operating system.
In one embodiment, the step of obtaining a peripheral device support module further comprises: the init flow is customized to automatically launch the client and server programs of the petitboost and the system components that depend on it.
In one embodiment, wherein introducing the udev and petitboost components in the Linux-based micro operating system includes adding support of petitboost components to UEFI firmware, so that petitboost utilizes runtime services (runtime service) provided by UEFI, thereby completing the function of the launcher, and providing implementation of petitboost components of the AARCH64 platform, in compliance with the petitboost platform support framework.
In one embodiment, the boot device is further configured to add an identification of a peripheral support module in the extended UEFI firmware, the peripheral support module managed by the UEFI boot manager, wherein running the extended UEFI firmware includes identifying whether the peripheral support module is present, and if the presence of the peripheral support module is identified, generating boot options defined in the UEFI specification; wherein booting the peripheral device support module to support the driving of the boot-type external device comprises booting the peripheral device support module if the boot option is selected.
In one embodiment, the boot option is selected through a UEFI boot manager or through a UEFI shell interface.
In one embodiment, the boot device is further configured to integrate the peripheral support module in the extended UEFI firmware or not to integrate the peripheral into the UEFI firmware, and to load the target operating system from the peripheral support module via the UEFI shell interface selection.
As described with reference to the above embodiments, by providing the extended UEFI firmware 101 and the boot device 102 in the system, the external device can be driven by the peripheral device support module to start the target operating system, thereby bypassing the problem that the UEFI firmware cannot drive the external device; the linux-based micro operating system is directly guided to a new kernel of a target operating system from a kernel which is currently running based on a kexec mechanism, so that a firmware link in a conventional guiding process can be completely avoided, and the target operating system can be quickly and easily started; wherein, the petitboost is used to finish the remote loading of the target operating system from the local block device or through network protocols such as FTP, SFTP, TFTP, NFS, HTTP, HTTPS and the like, so that the peripheral support module can realize the enumeration and loading of the target operating system; the method comprises the steps that by adding support of a Petitboot component to UEFI firmware, the Petitboot component can utilize runtime service provided by UEFI, and the problem that the conventional Petitboot component is mostly used for Sony PlayStation3 and an IBM OpenPower server and lacks support of platforms except for Power and PowerPC can be solved; and the identification of the peripheral equipment support module is added in the UEFI firmware, and the UEFI boot manager directly manages the boot mode, so that a user can know and control the boot process of the operating system more intuitively and select the boot mode of the target operating system more conveniently.
It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other.
In all of the embodiments provided herein, it should be understood that each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present disclosure. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes. It is noted that, herein, relational terms such as first and third, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The above is merely a preferred embodiment of the present disclosure and is not intended to limit the present disclosure, which may be variously modified and varied by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present disclosure should be included in the protection scope of the present disclosure. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.
The above is only a specific embodiment of the present disclosure, but the scope of the present disclosure is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present disclosure, and shall be covered by the scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the appended claims and their equivalents.
Claims (15)
1. A method for extending unified extensible firmware interface, UEFI, firmware to support driving of boot-type external devices, comprising:
running the extended UEFI firmware in response to loading the target operating system;
booting a peripheral support module to support driving of a boot-class external device that cannot be directly driven by UEFI firmware, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which extended UEFI firmware is to be loaded; and
loading a target operating system through the peripheral device support module after the boot-type external device is driven,
wherein the peripheral device support module is obtained by:
starting kexec and device mapper characteristics in a Linux-based micro operating system;
introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism;
the driver required for starting the external device is added into the micro operating system based on the Linux.
2. The method of claim 1, wherein said loading a target operating system by the peripheral support module comprises:
and loading the target operating system through a Kexec launcher of a petitboost component of the Linux-based micro operating system.
3. The method of claim 1, wherein the step of obtaining a peripheral support module further comprises:
the init flow is customized to automatically launch the client and server programs of the petitboost and the system components that depend on it.
4. The method of claim 1, wherein introducing udev and petitboost components in a Linux-based mini-operating system comprises:
adding the support of the Petitboot component to UEFI firmware, so that Petitboot utilizes runtime service (runtime service) provided by UEFI, thereby completing the function of the launcher;
following the platform support framework of Peitiboot, implementations of the Petitboot component of the AARCH64 platform are provided.
5. The method of claim 1 further comprising: adding identification of peripheral support modules in the extended UEFI firmware, managing the peripheral support modules by a UEFI boot manager,
wherein the UEFI firmware running the extension comprises:
identifying whether a peripheral device support module exists;
in the case that the existence of the peripheral equipment support module is recognized, generating a starting option defined by UEFI specification;
wherein the booting the peripheral device support module to support the driving of the boot-type external device comprises:
booting the peripheral support module if the start-up option is selected.
6. The method of claim 5, wherein the launch option is selected through a UEFI launch manager or through a UEFI shell interface.
7. The method of claim 1, further comprising integrating a peripheral support module in the extended UEFI firmware or not integrating a peripheral into the UEFI firmware, and selecting to load the target operating system from the peripheral support module through the UEFI shell interface.
8. An apparatus for extending Unified Extensible Firmware Interface (UEFI) firmware to support driving of boot-type peripherals, comprising:
a processor; and
a memory storing computer program instructions that, when executed by the processor, perform a method of extending UEFI firmware to support boot-type peripheral device drivers, the method comprising:
running the extended UEFI firmware in response to loading the target operating system;
booting a peripheral support module to support driving of a boot-class external device that cannot be directly driven by UEFI firmware, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which extended UEFI firmware is to be loaded; and
loading a target operating system through the peripheral device support module after the boot-type external device is driven,
wherein the peripheral device support module is obtained by:
starting kexec and device mapper characteristics in a Linux-based micro operating system;
introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism;
the driver required for starting the external device is added into the micro operating system based on the Linux.
9. The apparatus of claim 8, wherein the loading of the target operating system by the peripheral support module comprises:
and loading the target operating system through a Kexec launcher of a petitboost component of the Linux-based micro operating system.
10. The apparatus of claim 8, wherein the step of obtaining a peripheral support module further comprises:
the init flow is customized to automatically launch the client and server programs of the petitboost and the system components that depend on it.
11. The apparatus of claim 8, wherein introducing udev and petitboost components in a Linux-based mini-operating system comprises:
adding the support of the Petitboot component to UEFI firmware, so that Petitboot utilizes runtime service (runtime service) provided by UEFI, thereby completing the function of the launcher;
following the platform support framework of Peitiboot, implementations of the Petitboot component of the AARCH64 platform are provided.
12. The apparatus of claim 8, wherein the method further comprises adding an identification of a peripheral support module in the extended UEFI firmware, the peripheral support module managed by a UEFI boot manager,
wherein the UEFI firmware running the extension comprises:
identifying whether a peripheral device support module exists;
in the case that the existence of the peripheral equipment support module is recognized, generating a starting option defined by UEFI specification;
wherein the booting the peripheral device support module to support the driving of the boot-type external device comprises:
booting the peripheral support module if the start-up option is selected.
13. The apparatus of claim 12, wherein the launch option is selected through a UEFI launch manager or through a UEFI shell interface.
14. The apparatus of claim 8, wherein the method further comprises integrating a peripheral support module in the extended UEFI firmware or not integrating a peripheral into the UEFI firmware, and loading the target operating system from the peripheral support module via UEFI shell interface selection.
15. A system for extending unified extensible firmware interface, UEFI, firmware to support driving of boot-type external devices, comprising:
extended UEFI firmware; and
a guide device configured to:
running extended UEFI firmware;
booting a peripheral support module to support a driven component of a boot-class external device that the UEFI firmware cannot directly drive, wherein the peripheral support module is obtained by modifying a Linux-based micro operating system, wherein the Linux-based micro operating system is different from a target operating system to which the extended UEFI firmware is to be loaded; and
loading a target operating system through the peripheral device support module after the boot-type external device is driven,
wherein the peripheral device support module is obtained by:
starting kexec and device mapper characteristics in a Linux-based micro operating system;
introducing udev and petitboost components into a Linux-based micro operating system, wherein the petitboost component is a starter utilizing a Linux kexec mechanism;
the driver required for starting the external device is added into the micro operating system based on the Linux.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811599440.8A CN109614156B (en) | 2018-12-26 | 2018-12-26 | Method, device and system for supporting driving of starting type external equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811599440.8A CN109614156B (en) | 2018-12-26 | 2018-12-26 | Method, device and system for supporting driving of starting type external equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109614156A CN109614156A (en) | 2019-04-12 |
| CN109614156B true CN109614156B (en) | 2021-10-15 |
Family
ID=66011566
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811599440.8A Active CN109614156B (en) | 2018-12-26 | 2018-12-26 | Method, device and system for supporting driving of starting type external equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109614156B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111159700A (en) * | 2019-12-03 | 2020-05-15 | 北京工业大学 | Computer remote safe starting method and system based on UEFI system |
| CN111258661A (en) * | 2020-01-13 | 2020-06-09 | 山东超越数控电子股份有限公司 | RAID card drive design method based on UEFI SCSI |
| CN112130919A (en) * | 2020-09-28 | 2020-12-25 | 山东超越数控电子股份有限公司 | Fingerprint device self-adaption method, computer and fingerprint device |
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103150179A (en) * | 2013-02-07 | 2013-06-12 | 宝龙计算机系统（湖南）有限公司 | Method and device for obtaining swap space in UNIX-like operation system |
| CN103353929A (en) * | 2013-07-31 | 2013-10-16 | 山东超越数控电子有限公司 | Method for adding and checking ID card information in basic input/output system (BIOS) initiating process |
| CN103716867A (en) * | 2013-10-25 | 2014-04-09 | 华南理工大学 | Wireless sensor network multiple target real-time tracking system based on event drive |
| CN104364791A (en) * | 2012-03-06 | 2015-02-18 | 温科尼克斯多夫国际有限公司 | PC security using BIOS/(U)EFI extensions |
| CN104572165A (en) * | 2014-03-21 | 2015-04-29 | 中电科技（北京）有限公司 | UEFI (Unified Extensible Firmware Interface) firmware implementation method based on Feiteng server |
| CN104636092A (en) * | 2014-12-30 | 2015-05-20 | 珠海赛纳打印科技股份有限公司 | Image forming control system and method |
| CN104995629A (en) * | 2013-03-01 | 2015-10-21 | 英特尔公司 | Continuation of trust for platform boot firmware |
| CN105335264A (en) * | 2015-11-12 | 2016-02-17 | 浪潮电子信息产业股份有限公司 | Computer PCIE (Peripheral Component Interconnect Express) adapter card function testing method based on UEFI (Unified Extensible Firmware Interface) |
| CN105426293A (en) * | 2015-10-29 | 2016-03-23 | 汉柏科技有限公司 | Method and system for recording kernel exception stack and vmcore file |
| CN105446665A (en) * | 2015-12-18 | 2016-03-30 | 长城信息产业股份有限公司 | Computer storage acceleration system and optimization method thereof |
| CN105657464A (en) * | 2016-01-28 | 2016-06-08 | 四川长虹电器股份有限公司 | USB repeated node shielding method |
| CN105825131A (en) * | 2016-03-16 | 2016-08-03 | 广东工业大学 | Computer security startup protection method on basis of UEFI (Unified Extensible Firmware Interface) |
| CN106909399A (en) * | 2015-12-22 | 2017-06-30 | 中电科技（北京）有限公司 | A kind of UEFI firmware implementation methods based on server computer |
| CN107463388A (en) * | 2017-09-21 | 2017-12-12 | 成都领沃网络技术有限公司 | A kind of UEFI non-disk startups method |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TW201502782A (en) * | 2013-05-07 | 2015-01-16 | Insyde Software Corp | Os bootloader caching in non-volatile memory |
| US10146556B2 (en) * | 2013-11-21 | 2018-12-04 | Dell Products L.P. | System and method to perform an OS boot using service location protocol and launching OS using a dynamic update of network boot order without a reboot |
-
2018
- 2018-12-26 CN CN201811599440.8A patent/CN109614156B/en active Active
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104364791A (en) * | 2012-03-06 | 2015-02-18 | 温科尼克斯多夫国际有限公司 | PC security using BIOS/(U)EFI extensions |
| CN103150179A (en) * | 2013-02-07 | 2013-06-12 | 宝龙计算机系统（湖南）有限公司 | Method and device for obtaining swap space in UNIX-like operation system |
| CN104995629A (en) * | 2013-03-01 | 2015-10-21 | 英特尔公司 | Continuation of trust for platform boot firmware |
| CN103353929A (en) * | 2013-07-31 | 2013-10-16 | 山东超越数控电子有限公司 | Method for adding and checking ID card information in basic input/output system (BIOS) initiating process |
| CN103716867A (en) * | 2013-10-25 | 2014-04-09 | 华南理工大学 | Wireless sensor network multiple target real-time tracking system based on event drive |
| CN104572165A (en) * | 2014-03-21 | 2015-04-29 | 中电科技（北京）有限公司 | UEFI (Unified Extensible Firmware Interface) firmware implementation method based on Feiteng server |
| CN104636092A (en) * | 2014-12-30 | 2015-05-20 | 珠海赛纳打印科技股份有限公司 | Image forming control system and method |
| CN105426293A (en) * | 2015-10-29 | 2016-03-23 | 汉柏科技有限公司 | Method and system for recording kernel exception stack and vmcore file |
| CN105335264A (en) * | 2015-11-12 | 2016-02-17 | 浪潮电子信息产业股份有限公司 | Computer PCIE (Peripheral Component Interconnect Express) adapter card function testing method based on UEFI (Unified Extensible Firmware Interface) |
| CN105446665A (en) * | 2015-12-18 | 2016-03-30 | 长城信息产业股份有限公司 | Computer storage acceleration system and optimization method thereof |
| CN106909399A (en) * | 2015-12-22 | 2017-06-30 | 中电科技（北京）有限公司 | A kind of UEFI firmware implementation methods based on server computer |
| CN105657464A (en) * | 2016-01-28 | 2016-06-08 | 四川长虹电器股份有限公司 | USB repeated node shielding method |
| CN105825131A (en) * | 2016-03-16 | 2016-08-03 | 广东工业大学 | Computer security startup protection method on basis of UEFI (Unified Extensible Firmware Interface) |
| CN107463388A (en) * | 2017-09-21 | 2017-12-12 | 成都领沃网络技术有限公司 | A kind of UEFI non-disk startups method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109614156A (en) | 2019-04-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8751783B2 (en) | Booting computing devices with EFI aware operating systems | |
| US7136994B2 (en) | Recovery images in an operational firmware environment | |
| US8291209B2 (en) | Integration model for instant-on environment | |
| US9507604B2 (en) | Boot method and boot system | |
| CN109614156B (en) | Method, device and system for supporting driving of starting type external equipment | |
| JP6272991B2 (en) | Selective power management for pre-boot firmware updates | |
| TWI576764B (en) | A computer system | |
| US8443183B2 (en) | Pre-boot loader for reducing system boot time | |
| US11307907B2 (en) | Information handling system and method to automatically synchronize operating system and boot firmware languages | |
| CN109408122B (en) | Equipment starting method, electronic equipment and computer storage medium | |
| US20120042156A1 (en) | Method of multiple boot manager | |
| US7080244B2 (en) | System and method for configuring hardware devices using a menu for platforms with EFI and legacy option-ROMs | |
| CN113626822B (en) | UEFI firmware starting method and device integrating LinuxBoot | |
| US8316361B2 (en) | Method of enabling a user to update one or more low-level resources of a computer system in a user-friendly manner | |
| CN112506745A (en) | Memory temperature reading method and device and computer readable storage medium | |
| KR100678974B1 (en) | Apparatus and method for security and user comfortability in rebooting computer system | |
| US9411602B2 (en) | Techniques for booting an information processing system | |
| CN115220797A (en) | Operating system starting and deploying method, device, equipment, medium and program product | |
| CN113010215A (en) | Method, device and equipment for quickly restarting operating system and readable medium | |
| US20150212866A1 (en) | Management system for service of multiple operating environments, and methods thereof | |
| US8856666B2 (en) | Chassis button to activate graphical user interface to enable user to select diagnostic and/or recovery | |
| WO2008048581A1 (en) | A processing device operation initialization system | |
| US11301261B2 (en) | System and method for displaying an image through a platform initialization process | |
| CN115113941A (en) | System capable of loading BIOS preset configuration and method for loading BIOS preset configuration | |
| CN117311890B (en) | Picture display method and device in starting process of server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address |
Address after: 9th Floor, Building C, Gui'an Center, Plot ZD-64, Big Data Science and Technology Innovation City, Gui'an New Area, Guiyang City, Guizhou Province, 550003 (No. 2 on the south side) Patentee after: Guizhou Huaxin Semiconductor Technology Co.,Ltd. Address before: 550081 2nd floor, intersection of Qianzhong Avenue and Jinma Avenue, Gui'an New District, Guiyang City, Guizhou Province Patentee before: GUIZHOU HUAXINTONG SEMICONDUCTOR TECHNOLOGY Co.,Ltd. |
|
| CP03 | Change of name, title or address |