Display device, startup configuration file generation method and startup method

Abstract

The embodiment of the invention provides display equipment, a startup configuration file generation method and a startup method. According to the technical scheme, the display equipment respectively processes the tasks with different security levels in parallel through the master core and the slave core in the boot stage, so that the startup efficiency is effectively improved on the basis of ensuring the startup security and stability, and the waiting time of a user in the startup stage is shortened.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of display devices, and particularly relates to a display device, a startup configuration file generation method, and a startup method. BACKGROUND

[0002] The system startup speed of a display device is one of key indicators affecting user experience. The initial stage of the startup process, the Boot stage, undertakes a series of heavy tasks such as initializing hardware, detecting a key, booting a kernel and recovery mode, lighting a screen, displaying a startup logo, and running customized services. These tasks usually have to be completed before the operating system kernel is loaded, and the execution efficiency thereof directly determines the startup time perceived by a user. With increasing complexity, the number of tasks in the Boot stage continues to increase, resulting in a more prominent problem of time-consuming startup, which seriously affects the fast response capability of the device.

[0003] A multi-stage boot program design can be used to solve such problems, for example, the startup process is split into two consecutive Boots. Through task decomposition, the startup logic is intended to be straightened out. However, these Boot stages are usually arranged to be executed in series on the main processor core of the same CPU. Since Boot runs in the underlying bare machine environment, there is a lack of process scheduling and multi-threaded concurrency mechanisms of a high-level operating system, and all tasks can only be executed one by one in a predetermined order. Even if there are two Boots, real parallel processing cannot be achieved, and the utilization rate of computing resources is low.

[0004] Therefore, although the multi-Boot design is logically divided, it is limited by the single-core serial execution mode, and non-critical but time-consuming tasks will block the completion of critical path tasks, making it difficult to effectively shorten the time consumption of the entire Boot stage, and making the startup speed optimization fall into a bottleneck. That is, the processing mode based on serial processing cannot effectively improve the startup speed of the display device. SUMMARY

[0005] Embodiments of the application provide a display device, a startup configuration file generation method, and a startup method to solve the problem that the processing mode based on serial processing cannot improve the startup speed of the display device.

[0006] In a first aspect, embodiments of the application provide a display device, which comprises: a display; a controller, the controller comprising a master core and a slave core; the master core is configured to: load a first startup task configuration file into a running memory in response to a startup instruction; execute a first startup task based on the first startup task configuration file; the first startup task comprises a primary startup task and a secondary startup task; the security level of the secondary startup task is lower than that of the primary startup task; In a case that the first boot task execution is completed, the slave core is woken up; The slave core is configured to: After being woken up by the master core, the second boot task configuration file is loaded into the running memory; The second boot task is executed based on the second boot task configuration file; wherein the security level of the second boot task is lower than that of the first boot task; and the second boot task and the second-level boot task are executed in parallel.

[0007] In this way, by waking up the slave core at a specific node of the master core startup process, the second boot task with a lower security level can be executed in parallel with the remaining critical tasks on the master core. This design can realize multi-core parallel processing in the Boot phase, effectively utilize hardware resources, and split the originally serial task flow into two concurrent paths, thereby shortening the total time consumption of system startup and directly improving the user-perceived boot speed.

[0008] In some possible embodiments, further comprising: a memory including a first memory and a second memory; the first memory is used to store the task configuration file corresponding to the non-upgradable task, and the second memory is used to store the task configuration file corresponding to the upgradable task; the first boot task includes a first-level boot task and a second-level boot task; the master core is configured to execute the first boot task based on the first boot task configuration file, specifically: In response to a boot instruction, the first-level task configuration file is loaded from the first memory into the running memory; The first-level boot task is executed based on the first-level task configuration file; After the execution of the first-level boot task is completed, the second-level task configuration file is loaded from the second memory into the running memory; The second-level boot task is executed based on the second-level task configuration file.

[0009] In this way, by storing the first-level boot task configuration file, which determines whether the system can be normally started and is non-upgradable, in a dedicated first memory, the first-level boot task configuration file is physically isolated from the upgradable components. This approach effectively prevents damage to the most core boot code due to subsequent software upgrades or configuration errors, enhances the reliability and security of the system startup foundation, and provides a stable and trustworthy underlying environment for the execution of subsequent tasks.

[0010] In some possible embodiments, the slave core is configured to execute the loading of the second boot task configuration file to execute the second boot task, specifically: The second boot task configuration file is loaded from the second memory into the running memory; the storage space of the second boot task configuration file in the second memory is different from that of the second-level task configuration file.

[0011] In this way, the task configuration of the slave core is also from the second memory, but occupies a different storage space from the secondary task configuration of the master core. This division enables the master core to load its secondary tasks while the slave core simultaneously loads its own task configuration from another area, without interference. This not only avoids access conflicts, but also guarantees true parallel loading from the resource level, laying a solid foundation for subsequent parallel execution and further optimizing startup efficiency.

[0012] In some possible embodiments, the second startup task includes starting a customized function; the secondary startup task includes at least configuring a bottom-layer driver of the customized function; the master core is configured to execute the secondary startup task based on the secondary task configuration file, specifically configured to: read the customized function identifier through a preset interface; in a case where the customized function identifier indicates that the customized function has not been started, configure the bottom-layer driver corresponding to the customized function based on the bottom-layer driver parameter in the secondary task configuration file; send a configuration message to the slave core, the configuration message being used to indicate that the configuration of the bottom-layer driver corresponding to the customized function is completed.

[0013] In this way, by decomposing the startup process of the customized function, the master core is responsible for configuring the key bottom-layer driver, and the slave core is responsible for the upper-layer application logic. This design enables the master core with the highest security level to control the core link of hardware resource configuration, ensuring the stability and security of the system, and creating conditions for the slave core to start the application-layer function as soon as possible, which is conducive to realizing safe and efficient startup of complex functions under a parallel architecture.

[0014] In some possible embodiments, the slave core is configured to execute the second startup task based on the second task configuration file, specifically configured to: read the customized function identifier bit through a preset interface; in a case where the customized function identifier bit indicates that the customized function has not been started, listen to the configuration message; in a case where the configuration message is received, set the customized function identifier of the customized function corresponding to the configuration message to a startup identifier.

[0015] In this way, the slave core starts the function by listening to the configuration completion message sent by the master core, ensuring that the slave core can start after the bottom-layer environment is prepared by the master core. This design can effectively avoid hardware exceptions caused by improper access when the driver is not configured, and ensure the correctness and timing of function initialization in the asynchronous execution scenario of the master and slave cores.

[0016] In some possible embodiments, after the master core sends the configuration message to the slave core, the master core is further configured to: If the customized function identifier is not read to change within a preset time, a reset instruction is generated; the reset instruction is used to instruct the display device to restart the boot process.

[0017] In this way, when the abnormal communication between the master and slave cores causes the customized function to fail to start as scheduled, the system can automatically restart after a timeout. This prevents the device from being stuck in a certain startup intermediate state for a long time due to the task of the slave core being stuck, forming a "fake death", thereby improving the robustness of the system when facing sudden abnormalities.

[0018] In some possible embodiments, the master core is configured to wake up the slave core when the first boot task is executed to a preset stage, specifically by: In some possible embodiments, the master core is configured to wake up the slave core when the first boot task is executed to a preset stage, specifically by:

[0019] In this way, by waking up the slave core after the first boot task is completely executed, it is ensured that the most basic and core hardware and software environment of the system is in a stable and reliable state. On this solid foundation, the slave core is started to execute parallel tasks, which not only improves the speed, but also maximizes the risk of early start failure that may be caused by the unprepared core environment.

[0020] In some possible embodiments, the master core is configured to wake up the slave core when the first boot task is executed to a preset stage, specifically by: modifying a running identifier corresponding to the slave core; the running identifier is used to instruct the task execution process of the slave core; The slave core is configured to load the second boot task configuration file into the running memory, specifically by: reading the running identifier; loading the second boot task configuration file based on the running identifier.

[0021] In this way, by modifying a shared running identifier, the master core can instruct the task loading process of the slave core. The slave core triggers the task loading by reading the identifier, and the whole process does not require a complex inter-process communication protocol, has very small overhead, and responds quickly. This design is very suitable for the Boot stage environment with limited resources and pursuit of efficiency.

[0022] In a second aspect, the embodiments of the present application provide a boot configuration file generation method, comprising: setting a first compiling macro and a second compiling macro in a compiling rule file, the first compiling macro is used to indicate a compiling rule which can generate a first compiling rule file, the first compiling rule file is used to indicate a first to-be-compiled code which can generate a first boot task configuration file, the first boot task configuration file is used to execute a first boot task; the second compiling macro is used to indicate a compiling rule which can generate a second compiling rule file, the second compiling rule file is used to indicate a second to-be-compiled code which can generate a second boot task configuration file, the second boot task configuration file is used to execute a second boot task; a security level of the second boot task is lower than that of the first boot task; generating the first compiling rule file and the second compiling rule file according to the compiling rule file, the first compiling macro and the second compiling macro; generating a first-level boot configuration file in the first boot task configuration file based on the first code library and the first compiling rule file; the first-level boot configuration file corresponds to a non-upgradable task; generating a second-level boot configuration file in the first boot task configuration file based on the second code library and the first compiling rule file; the second-level boot task configuration file corresponds to an upgradable task; generating the second boot task configuration file based on the second code library and the second compiling rule file.

[0023] In this way, the architecture design of parallel starting is implemented and fixed in the software compiling stage. Through different compiling macros and code libraries, tasks with different security levels and different attributes are physically separated into independent configuration files when the source code is constructed. This ensures the security of master-slave core tasks from the root, makes the parallel design clear and controllable, and provides convenience for subsequent secure starting, independent upgrading and system maintenance.

[0024] In a third aspect, an embodiment of the present application provides a boot starting method, comprising: loading, by a master core, a first boot task configuration file to a running memory in response to a boot instruction; executing, by the master core, a first boot task based on the first boot task configuration file; awakening, by the master core, a slave core in a case where the first boot task is executed to a preset stage; loading, by the slave core, a second boot task configuration file to the running memory; executing, by the slave core, a second boot task based on the second boot task configuration file; wherein a security level of the second boot task is lower than that of the first boot task; the second boot task and the remaining first boot task are executed in parallel. BRIEF DESCRIPTION OF DRAWINGS

[0025] In order to more clearly illustrate the technical solutions of the present application, the following will briefly introduce the drawings needed in the embodiments. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without any creative effort.

[0026] Figure 1 A schematic diagram of a display device operation scenario provided for some embodiments of the present application; Figure 2 A hardware configuration schematic diagram of a display device provided for some embodiments of the present application; Figure 3 A software configuration schematic diagram of a display device provided for some embodiments of the present application; Figure 4 A single-core booting schematic diagram of a display device provided for some embodiments of the present application; Figure 5 A flowchart of dual-core booting of a display device provided for some embodiments of the present application; Figure 6 A flowchart of a main core executing step S200 of a display device provided for some embodiments of the present application; Figure 7 A flowchart of a main core executing step S300 of a display device provided for some embodiments of the present application; Figure 8 A flowchart of a main core executing step S100 and a slave core executing step S400 of a display device provided for some embodiments of the present application; Figure 9 A flowchart of a main core executing step S240 of a display device provided for some embodiments of the present application; Figure 10 A flowchart of a slave core executing step S500 of a display device provided for some embodiments of the present application; Figure 11 A judgment flowchart of a display device generating a reset instruction provided for some embodiments of the present application; Figure 12 A flowchart of a booting configuration file compiling method provided for some embodiments of the present application; Figure 13 A schematic diagram of a booting configuration file compiling provided for some embodiments of the present application. DETAILED DESCRIPTION

[0027] The embodiments will be described in detail below with reference to the drawings. Unless otherwise indicated, the same numbers on different drawings represent the same or similar elements. The embodiments described in the following description are not meant to be exhaustive or to be limited to the precise forms disclosed. These embodiments are chosen and described to best explain the principles of the application and its best mode which can be employed to implement the application.

[0028] It should be noted that the brief description of the terms in this application is only for the convenience of understanding the embodiments described below, and is not intended to limit the embodiments of the application. Unless otherwise specified, these terms should be understood according to their ordinary and general meanings.

[0029] The terms "first", "second", "third" and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean a specific order or sequence, unless otherwise noted. It should be understood that the terms used in this way can be interchanged under appropriate circumstances.

[0030] The terms "include" and "have" and any variations thereof are intended to cover but not exclusive inclusion, for example, a product or device including a series of components does not necessarily limit to all components clearly listed, but can include other components not clearly listed or inherent to these products or devices.

[0031] The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic or combination of hardware or / and software code capable of performing functions related to the element.

[0032] In the embodiments of the present application, the display device 200 generally refers to a device with picture display and data processing capability. For example, the display device 200 includes but is not limited to smart television, mobile terminal, computer, monitor, advertising screen, wearable device, virtual reality device, augmented reality device, etc.

[0033] Figure 1 The schematic diagram of the operation scenario between the display device and the control device provided by some embodiments of the present application is shown. As shown in Figure 1 The user can operate the display device 200 through touch operation, mobile terminal 300 and control device 100. For example, the control device 100 can be a remote controller, a stylus, a handle, etc.

[0034] The mobile terminal 300 can be used as a kind of control device for performing human-computer interaction between the user and the display device 200. The mobile terminal 300 can also be used as a kind of communication device for establishing communication connection with the display device 200 and performing data interaction. In some embodiments, the mobile terminal 300 can install software application with the display device 200, realize connection communication through network communication protocol, and achieve the purpose of one-to-one control operation and data communication. The audio and video content displayed on the mobile terminal 300 can also be transmitted to the display device 200 to realize synchronous display function.

[0035] As shown in Figure 1It is also shown that the display device 200 also communicates data with the server 400 through various communication modes. The display device 200 can be allowed to communicate through a local area network (LAN), a wireless local area network (WLAN), and other networks.

[0036] The display device 200 can provide a broadcast receiving television function, and can also provide an intelligent network television function additionally provided with computer support functions, including but not limited to a network television, a smart television, an Internet protocol television (IPTV), and the like.

[0037] Figure 2 The display device 200 provided for some embodiments of the present application Figure 1 The hardware configuration block diagram of the display device 200 is shown in the figure.

[0038] In some embodiments, the display device 200 can include at least one of a tuning demodulator 210, a communication device 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a memory, a power supply, and a user input interface.

[0039] In some embodiments, the detector 230 is used to collect signals of external environments or external interactions. For example, the detector 230 can include a millimeter wave radar, which can be used to detect whether a user is contained within a preset range. The detector 230 can also include a sound collector to collect voice instructions input by a user through the sound collector.

[0040] In some embodiments, the display 260 includes a display functional component for presenting a picture, and a driving component for driving image display. The display 260 is used to receive image signals output from the controller 250 for display. For example, the display 260 can be used to display video content, image content, components of a menu control interface, and a user control UI interface, and the like.

[0041] In some embodiments, the communication device 220 is a component for communicating with external devices or the server 400 according to various communication protocol types. The display device 200 can be provided with multiple communication devices 220 according to different supported communication modes. For example, when the display device 200 supports wireless network communication, the display device 200 can be provided with a communication device 220 including a WiFi function. When the display device 200 supports Bluetooth connection communication, the display device 200 needs to be provided with a communication device 220 including a Bluetooth function.

[0042] The communication device 220 can connect the display device 200 to the external device or the server 400 in a communication manner of wireless or wired connection. The wired connection can connect the display device 200 to the external device through a data line, an interface, or the like. The wireless connection can connect the display device 200 to the external device through a wireless signal or a wireless network. The display device 200 can establish a connection relationship with the external device directly or indirectly through a gateway, a router, a connection device, or the like.

[0043] In some embodiments, the controller 250 can include at least one of a central processor, a video processor, an audio processor, a graphic processor, a power processor, a first interface to an n-th interface for input / output, and the controller 250 controls the operation of the display device and responds to the user's operation by controlling various software control programs stored on the memory. The controller 250 controls the overall operation of the display device 200.

[0044] In some embodiments, the controller 250 and the tuner demodulator 210 can be located in different split devices, i.e., the tuner demodulator 210 can also be located in an external device of the main device where the controller 250 is located, such as an external set-top box, etc.

[0045] In some embodiments, the user can input a user command through a graphical user interface (GUI) displayed on the display 260, and the user input interface receives the user input command through the graphical user interface (GUI).

[0046] In some embodiments, the audio output device 270 can be a native speaker of the display device 200, or an audio output device connected to the display device 200. For the audio output device connected to the display device 200, the display device 200 can also be provided with an external audio output terminal, and the audio output device can be connected to the display device 200 through the external audio output terminal to output the sound of the display device 200.

[0047] In some embodiments, the user input interface 280 can be used to receive instructions input from the user. The user input interface 280 can include at least one of a microphone, a touchpad, a sensor, a remote controller, etc. The display device 200 can then perform an interactive function with the user based on the instructions input from the user through the user input interface 280.

[0048] In some embodiments, to enable user interaction, the display device 200 may run an operating system. An operating system is a computer program that manages and controls the hardware and software resources of the display device 200. The operating system can control the display device to provide a user interface; for example, the operating system can directly control the display device to provide a user interface, or it can provide a user interface by running applications. The operating system also allows users to interact with the display device 200.

[0049] It should be noted that the operating system can be a native operating system based on a specific operating platform, a third-party operating system that is deeply customized based on a specific operating platform, or an independent operating system specifically developed for display devices.

[0050] An operating system can be divided into different modules or levels based on the functions it implements, for example... Figure 3 As shown, in some embodiments, the system is divided into four layers, from top to bottom: the Applications layer (referred to as the "Application Layer"), the Application Framework layer (referred to as the "Framework Layer"), the System Library layer, and the Kernel layer.

[0051] In some embodiments, the application layer provides services and interfaces for applications, enabling the display device 200 to run applications and interact with the user based on the applications. The application layer may contain at least one application, which may be a built-in Windows program, system settings program, or clock program of the operating system; or it may be an application developed by a third-party developer. In specific implementations, the application packages in the application layer are not limited to the examples above.

[0052] The framework layer provides application programming interfaces (APIs) and a programming framework for applications. The application framework layer includes predefined functions. It acts as a central processing unit, determining the actions taken by applications within the application layer. Through the API, applications can access system resources and obtain system services during execution.

[0053] like Figure 3As shown, the application framework layer in this embodiment includes a view system, managers, and content providers. The view system designs and implements the application's interface and interactions, and includes lists, grids, text boxes, and buttons. The managers include at least one of the following modules: an activity manager for interacting with all running activities in the system; a location manager for providing system services or applications with access to system location services; a package manager for retrieving various information related to application packages currently installed on the device; a notification manager for controlling the display and clearing of notification messages; and a window manager for managing icons, windows, toolbars, wallpapers, and desktop widgets on the user interface.

[0054] In some embodiments, the Activity Manager manages the lifecycle of individual applications and common navigation and back functions, such as controlling application exit, opening, and back actions. The Window Manager manages all window programs, such as obtaining the screen size, determining if a status bar is present, locking the screen, capturing the screen, and controlling changes to the display window, such as shrinking the display window, shaking the display, or distorting the display.

[0055] In some embodiments, the system runtime library layer can provide support for the framework layer. When the framework layer is used, the operating system runs the instruction library contained in the system runtime library layer, such as the C / C++ instruction library, to implement the functions to be performed by the framework layer.

[0056] In some embodiments, the kernel layer is a functional layer situated between the hardware and software of the display device 200. The kernel layer can implement functions such as hardware abstraction, multitasking, and memory management. For example, ... Figure 3 As shown, hardware drivers can be configured in the kernel layer. The kernel layer can contain at least one of the following drivers: audio driver, display driver, Bluetooth driver, camera driver, WIFI driver, USB driver, HDMI driver, sensor driver (such as fingerprint sensor, temperature sensor, pressure sensor, etc.), and power driver, etc.

[0057] Based on such Figures 2-3 With the provided hardware support and software architecture, the display device 200 can enter the boot process upon receiving a power-on command. For example... Figure 4As shown, in the process of starting up, the display device 200 needs to enter the boot stage, and then the main core of the display device 200 completes multiple tasks such as initializing the hardware environment, key value detection, booting the kernel, loading customized functions, and the like in the boot stage. There is no process management unit or scheduling unit in the running environment of the boot, and it is difficult to support the task loading mode of multiple processes or multiple threads, so the main core needs to serially execute these tasks, resulting in a long boot startup time, that is, slow boot speed of the display device 200.

[0058] To solve the above problems, an embodiment of the present application provides a display device 200, which comprises a display 260 and a controller 250. The controller 250 comprises a main core and a slave core, wherein the main core and the slave core are both processing cores with independent computing and logical capabilities, so that the main core and the slave core can process the tasks of the boot stage in parallel.

[0059] As shown, the main core is configured to: Figure 5 S100: In response to a startup instruction, load a first startup task configuration file into the memory.

[0060] S200: Execute a first startup task based on the first startup task configuration file.

[0061] S300: In the case where the first startup task is executed to a preset stage, wake up the slave core.

[0062] The first startup task configuration file can include codes for the boot stage and control logic. The code part can include, for example, hardware initialization code, system key resource setting code, system driver code, error correction code. The control logic part can include, for example, security verification logic, flow control logic, and the like. That is, the first startup task configuration file can be used as a reference file / execution file of the main core in the boot stage, and the main core can execute multiple tasks with higher security level such as hardware initialization, driver configuration and the like of the display device 200 in the boot stage by loading the first startup task configuration file.

[0063] In some embodiments, the main core can first load the first startup task configuration file into the running memory in the case where the startup instruction is received, and then the main core can load the codes and control logic in the first startup task configuration file from the running memory to execute tasks such as hardware initialization, driver configuration and the like according to the codes and control logic.

[0064] ​After the master core completes the basic hardware initialization, driver configuration and other tasks, the master core can wake up the slave core to handle the remaining boot phase tasks in parallel with the slave core. Among them, the basic hardware initialization, driver configuration refers to the task with relatively simple logic in the boot phase. After the execution of this part of the relatively simple task, it can be ensured that the display device 200 can start up, but at this time the driver configuration and hardware initialization are not complete, so the display device 200 cannot perform complex customization tasks such as screen tapping, boot animation, etc.

[0065] Therefore, the master core can wake up the slave core to handle these tasks in parallel. On the one hand, the master core can continue to perform the hardware initialization task and the driver configuration task with complex logic. On the other hand, the slave core can load the customization tasks such as level, boot animation, etc. after the master core configures the complex underlying driver, thereby realizing the parallel processing of the master core and the slave core in the boot phase.

[0066] As shown in Figure 5 The slave core is configured to: S400: Load the second boot task configuration file into the memory.

[0067] S500: Execute the second boot task based on the second boot task configuration file.

[0068] The second boot task configuration file can include code and control logic for the boot phase. Among them, the code part can include customization tasks such as boot animation code and screen tapping code. The control logic can include the execution logic of the customization task, such as which modules need to be started in sequence during the execution of the boot animation. Then the slave core can execute the customization task according to the code and control logic provided by the second boot task configuration file.

[0069] In some embodiments, the slave core can load the second boot task configuration file into the running memory of the display device 200 when it is woken up. Then the slave core can load the code and control logic in the second boot task configuration file in the running memory to execute the customization task and other tasks with lower security level according to these code and control logic.

[0070] In this way, the master core can wake up the slave core after completing the basic initialization, driver configuration and other tasks, and continue to perform the initialization, driver configuration and other tasks with complex logic. The slave core can execute the second boot task with lower security level such as customization task after being woken up.

[0071] The second boot task has a lower security level than the first boot task. Then, the task with a higher security level is still allocated to the main core for processing, and the task with a lower security level is allocated to the slave core for processing, so as to form a running architecture in which the main core and the slave core perform various tasks in parallel in the boot phase. Based on the running architecture in parallel, the boot efficiency of the display device 200 can be effectively improved. Moreover, by allocating tasks with different security levels to different cores, the system security of the display device 200 in the boot phase can be effectively ensured.

[0072] It should be noted that the first boot task includes an upgradeable part and a non-upgradeable part. The non-upgradeable part refers to the task with the highest security level, i.e., the task for supporting the boot function of the display device 200, such as the task of initializing the clock of the CPU, the memory controller, etc. Although such tasks are also embodied in hardware initialization, driver configuration, etc. in terms of task execution mode, such tasks are likely to cause the display device 200 to be difficult to start if modified.

[0073] The upgradeable part refers to the task with a slightly lower security level than the non-upgradeable part, such as the task of initializing peripherals, detecting keys, etc. Such tasks can be iterated with the project or the hardware, and will not affect the normal execution of the boot process of the display device 200.

[0074] Therefore, from the perspective of system update security of the display device 200, integrating the two types of tasks together is not conducive to system update and is not conducive to distinguishing the security levels of the tasks, resulting in a decrease in system security of the display device 200 in the start-up process and a decrease in system security in the system update phase.

[0075] In some embodiments, the display device 200 includes a memory, and then the configuration files corresponding to the tasks of the non-upgradeable part and the tasks of the upgradeable part can be stored in different memories. As shown in Figure 6 The main core executes the first boot task based on the first boot task configuration file, and is specifically configured to: S210: In response to a boot instruction, loading the first-level task configuration file from the first memory to the memory.

[0076] S220: Executing the first-level boot task based on the first-level task configuration file.

[0077] S230: After the first-level boot task is executed, loading the second-level task configuration file from the second memory to the memory.

[0078] S240: Executing the second-level boot task based on the second-level task configuration file.

[0079] In some examples, the memory can include a first memory and a second memory, wherein the first memory can be a chip ROM or a protected read-only memory, and the first memory is configured to store a task configuration file corresponding to a non-upgradable task, i.e., a first-level task configuration file. The second memory can be an external storage partition such as an eMMC, and the second memory is configured to store a task configuration file corresponding to an upgradable task, i.e., a second-level task configuration file.

[0080] It can be understood that the main core actually divides the boot stage into two levels in the process of executing the first boot task. In the first-level boot stage, the main core performs tasks such as CPU initialization, serial port initialization, and clock initialization to support the basic boot function of the display device 200 by loading the first-level task configuration file. Further, after the completion of these tasks, the main core performs more complex hardware initialization and underlying driver configuration, such as configuring the underlying driver of the customized task and initializing the peripheral device, by loading the second-level task configuration file.

[0081] In this way, the main core can read the code and control logic in the first-level task configuration file or the second-level task configuration file only when the first-level task configuration file or the second-level task configuration file is loaded into the running memory. Therefore, the main core needs to load the corresponding task configuration file into the running memory before executing the first-level boot task and the second-level boot task to facilitate access.

[0082] By dividing the boot stage of the main core into two levels, the main core provides a running environment and a support framework for the display device 200 in the first-level boot stage, thereby providing a basis for the subsequent boot stage. Then, the main core constructs the underlying driver and provides basic hardware parameters for the display device 200 in the second-level boot stage. On the one hand, the task configuration files corresponding to different boot stages can be set in different storage spaces to avoid the decline of system security and stability caused by package updates. On the other hand, by splitting the first boot task, the task execution timing of the first-level boot stage and the second-level boot stage can be effectively controlled, thereby facilitating the determination of the timing of waking up the slave core and improving the system security and stability of the parallel execution of tasks by the main core and the slave core.

[0083] In some embodiments, the completion of the first-level boot task corresponds to the main core executing the first boot task reaching a preset stage. At this node, the main core can start the second-level boot task based on the booting part in the first-level boot task and wake up the slave core. Specifically, the main core waking up the slave core is configured as: In the case where the first-level boot task is executed, the slave core is woken up by modifying the wake-up identifier of the wake-up register.

[0084] In some examples, the primary boot task can include code and control logic for waking up the slave core, and also include code and control logic for waking up the secondary boot task. After the main core completes the hardware initialization, driver configuration, and other tasks in the primary boot task, the main core wakes up the slave core and the secondary boot stage according to the code and control logic in the primary task configuration file. This ensures the coordination of the slave core and the main core during the startup process, and ensures that the slave core can perform customized tasks such as screen pointing, displaying the boot logo, etc. After the slave core is woken up, the second boot task configuration file is immediately loaded from the second memory to the running memory, and the customized display tasks such as screen pointing initialization, backlight adjustment, and boot logo rendering are performed according to the control logic therein.

[0085] The main core can wake up the slave core by modifying a hardware register used to control the state of the slave core.

[0086] The slave core is woken up after the main core completes the primary boot, and its startup timing is precisely synchronized with the main core, avoiding resource contention and access conflicts. By decentralizing critical display functions to the slave core for independent execution, the load on the main core is reduced, and the system response speed and task parallelism are improved. At the same time, the independent storage and loading mechanism of the second boot task configuration file ensures the security and updateability of the slave core execution environment.

[0087] As shown in Figure 7 , the main core can wake up the slave core in the process of waking up the slave core, and the slave core can accurately and quickly enter the boot stage in combination with the control of the running identification bit. Specifically, the main core is configured to: modify the running identification bit corresponding to the slave core.

[0088] The slave core is configured to load the second boot task configuration file into the memory, specifically by: reading the running identification bit.

[0089] loading the second boot task configuration file based on the running identification bit.

[0090] The running identification bit is used to indicate the type of task execution of the slave core. The running identification bit can be stored in a preset register, and the main core and the slave core can read the running identification bit or access it through shared memory. In addition, the main core also has the ability to modify the running identification bit to indicate the slave core to enter a specific boot mode.

[0091] In some embodiments, after the primary core completes the hardware initialization and driver configuration of the first boot task, the primary core modifies the running identification bit corresponding to the secondary core by writing into a preset register, and sets the running identification bit to a "second boot task execution state". After the secondary core is powered on, the secondary core continuously detects the running identification bit in the register. If the running identification bit is detected to be in the "second boot task execution state", the secondary core immediately performs an operation of loading a second boot task configuration file into a running memory, and performs a corresponding processing flow according to the control logic in the configuration file.

[0092] In some examples, taking a boot animation as an example, the secondary core controls the display timing and transition effect of each frame according to the time axis and display parameters in the second boot task configuration file. Through an independent graphics processing channel, the secondary core ensures the smoothness of the animation while avoiding the performance loss of the primary core caused by frequent image scheduling.

[0093] In this way, based on the setting of the running identification bit, the primary core and the secondary core achieve precise cooperation of the startup process, and ensure that the secondary core cuts in and performs the exclusive task at the correct time. The running identification bit as the key signaling of the dual-core communication not only simplifies the wake-up logic, but also supports flexible expansion of multiple startup modes. Through the mechanism, the system can dynamically allocate tasks in different boot scenarios, and improve the resource utilization and startup efficiency.

[0094] The primary core can wake up the secondary core after completing the execution of the first boot task, so that the secondary core synchronously executes a task with a lower security level, such as a customized task, in the process that the primary core executes the second boot task. Figure 8 As shown in FIG. 7, the secondary core executes the loading of the second boot task configuration file to execute the second boot task, and is specifically configured as follows: loading the second boot task configuration file from the second memory into the memory.

[0095] In some embodiments, the second boot task configuration file and the first task configuration file are respectively stored in the second memory and the first memory. The second boot task configuration file can be stored in the same memory as the second task configuration file, and different storage spaces can be divided in the memory to respectively store the second boot task configuration file and the second task configuration file.

[0096] In this way, after the secondary core is woken up, the secondary core can find the second boot task configuration file from the second memory and load the second boot task configuration file into the running memory. Then, the secondary core can access the second boot task configuration file in the running memory to execute tasks such as customized functions.

[0097] The slave core can participate in the boot stage of the display device 200 by loading the second boot task configuration file after being woken up from the core, and then execute the boot task in parallel with the master core. The running process of the slave core coincides with the second boot stage of the master core, and then the slave core can execute the task specified in the second boot task configuration file in combination with the task execution of the master core in the second boot stage. Meanwhile, the master core can control its task execution process according to the task execution of the slave core in the second boot stage.

[0098] In some embodiments, the second boot task includes starting a customized function, and the second boot task includes at least configuring a bottom driver of the customized function. Then, the master core and the slave core need to determine whether to continue to execute other tasks according to the respective task execution.

[0099] As shown in FIG. 8, the master core executes the second boot task based on the second task configuration file, which is specifically configured as follows: Figure 9 S241: reading a customized function identifier through a preset interface. S242: in the case that the customized function identifier represents that the customized function has not been started, configuring a bottom driver corresponding to the customized function based on the bottom driver parameter configuration in the second task configuration file.

[0100] S243: sending a configuration message to the slave core, the configuration message being used to represent that the configuration of the bottom driver corresponding to the customized function is completed.

[0101] Taking the execution of the customized function as an example, the master core and the slave core can call the same preset interface to read the configuration process of the customized function. The master core and the slave core can also realize inter-core communication through a preset communication mode to transmit configuration messages to each other, and trigger the action of reading the configuration process of the customized function through the preset interface based on the configuration message. Each customized function can be preset with a corresponding customized function identifier bit, and the completion of the configuration of the customized function can be determined by modifying the customized function identifier bit.

[0102] In some embodiments, the master core can call the preset interface to check the customized identifier bit of each customized function at a preset time interval during the process of configuring the bottom driver of the customized function. And in the case that the customized function is not started, the bottom driver corresponding to the customized function is configured according to the bottom driver parameter in the second task configuration file. After the master core completes the configuration of the bottom driver of the customized function, the master core can send a configuration message to the slave core to prompt the slave core that the bottom driver of the customized function has been configured.

[0103]

[0104] ​In some examples, the preset interface can select GetDeviceInfo(), that is, the master core judges whether the customized function is configured by calling GetDeviceInfo(), and in the case of completion, the subsequent function configuration is normally executed.

[0105] In the case of not being completed, the configuration of the customized function is configured, for example, the parameter configuration of the power management register, the register of the memory controller, and the register of the display controller related to the customized function, to build the underlying driver supporting the customized function. And further, the configuration message can be sent to the slave core through the mailbox communication mechanism.

[0106] Among them, based on the mailbox communication mechanism, the physical memory for storing messages can be defined, and the length of the physical memory can be selected as 4 bytes, each bit representing a message, and then supporting 32 kinds of message interaction. The master core and the slave core can read the corresponding messages based on the mailbox communication mechanism, and execute the tasks corresponding to the messages.

[0107] In addition, the mailbox communication mechanism can define g_data_offset as a global offset, and then the global offset can be used to limit the location of the configuration message in the physical memory, that is, the write address of the configuration message each time = the base address of the physical memory + the global offset. After each write of the configuration message, the global offset is updated, and then when writing the configuration message next time, the configuration message will be written to the address adjacent to the previous configuration message. Thus, the order of reading the configuration message by the master core or the slave core is effectively limited, that is, the task execution order of the master core or the slave core is effectively limited, and the reliable transmission of data is also ensured, thereby ensuring the safety and stability of the master core and the slave core in parallel executing the boot task.

[0108] As shown in Figure 10 The slave core can also determine the configuration process of the customized function by reading the customized function identification bit, that is, the slave core executes the second boot task based on the second boot task configuration file to execute the second boot task, which is specifically configured as: S510: reading the customized function identification bit through the preset interface.

[0109] S520: in the case that the customized function identification bit represents that the customized function is not started, listening to the configuration message.

[0110] S530: in the case that the configuration message is received, setting the customized function identification of the customized function corresponding to the configuration message to a start identification.

[0111] In some embodiments, during the execution of the second boot task, the slave kernel can read the customization feature flag by calling GetDeviceInfo(). After reading the flag indicating that the customization feature has been configured, other boot tasks can continue to be executed.

[0112] If the slave core detects that a customization feature is incomplete, it will listen for configuration messages updated by the master core or query the physical memory used to store configuration messages. This allows the slave core to quickly retrieve new configuration messages from the master core and set the customization feature flag corresponding to those messages as the start flag.

[0113] In some examples, after the master core sends a configuration message to the slave core, it can identify that the customization function has been configured by calling GetDeviceInfo(). Once both the master and slave cores have confirmed that the customization function is configured, it means that the function can run during the boot process. Taking boot animation playback as an example, after the master and slave cores confirm that the boot animation configuration is complete, the display device 200 can enter the boot animation playback phase.

[0114] It is understandable that the execution order of the customized functions during the boot phase of the display device 200 corresponds to the configuration order of the customized functions by the main core and the slave core during the boot phase.

[0115] In this way, the master and slave cores achieve efficient collaboration and state synchronization through preset interfaces, customized function identifiers, and mailbox communication mechanisms, ensuring the orderly configuration and reliable execution of customized functions during the multi-core system startup process. A unified memory mapping mechanism guarantees data consistency, avoiding resource contention and access conflicts.

[0116] It should be noted that although resource contention and access conflicts can be effectively avoided during the architecture design process to minimize startup failures caused by resource conflicts, the display device 200 may still experience boot abnormalities during the boot phase due to poor circuit contact, temporary communication failures, or other reasons.

[0117] like Figure 11 As shown, after the master core sends the configuration message to the slave core, it is also configured as follows: If no change is detected in the customized function identifier within a preset time, a reset command is generated. The reset command is used to restart the boot process of the display device.

[0118] In some embodiments, the master core can start a timer after sending the configuration information, and set a preset time threshold for monitoring the response status of the slave core. If the customized function identification bit is not updated to the start identification within the preset time, it is determined that the communication is abnormal or the slave core processing fails, and the master core triggers a reset mechanism to force the system to restart to re-execute the boot process.

[0119] In this way, the system can be effectively prevented from being in a stagnant state due to communication delay or slave core abnormality, and the reliability and stability of the boot process are ensured.

[0120] In other embodiments, the master core can also generate a reset instruction to restart the boot process in the case of abnormality during the execution of the first boot task. The master core will trigger the reset mechanism when detecting that the key task execution times out or returns an error state, so as to ensure that the system will not be in an abnormal state.

[0121] Through the design of the reset mechanism, the fault tolerance and stability of the boot process under the cooperation of multiple cores can be further improved, and the device can still be reliably started under various abnormal scenarios.

[0122] As shown in Figure 12 The embodiment of the present application provides a boot configuration file generation method, which comprises: S10: setting a first compilation macro and a second compilation macro in a compilation rule file, the first compilation macro being used to indicate a compilation rule that can generate a first compilation rule file, the first compilation rule file being used to indicate a first to-be-compiled code that can generate a first boot task configuration file; the second compilation macro being used to indicate a compilation rule that can generate a second compilation rule file, the second compilation rule file being used to indicate a second to-be-compiled code that can generate a second boot task configuration file; S20: generating the first compilation rule file and the second compilation rule file according to the compilation rule file, the first compilation macro and the second compilation macro; S30: generating a first-level boot configuration file in the first boot task configuration file based on a first code library and the first compilation rule file; the first-level boot configuration file corresponding to a non-upgradable task; S40: generating a second-level boot configuration file in the first boot task configuration file based on a second code library and the first compilation rule file; the second-level boot task configuration file corresponding to an upgradable task; S50: generating a second boot task configuration file based on the second code library and the second compilation rule file; the security level of the second boot task being lower than that of the first boot task.

[0123] As shown in Figure 13As shown, the compilation rule file can be composed of a software development kit makefile (Software Development Kit Makefile, SDK Makefile), a software development kit configuration file (Software Development Kit Configuration File, SDK CONFIG).

[0124] In the process of compiling the boot task configuration file, each boot task configuration file can be compiled in combination with a compilation macro, which is used to indicate which rules apply to the specific compilation process, thereby realizing differentiated processing of tasks of different security levels and upgrade attributes.

[0125] In some embodiments, the generation path and generation rules of the first and second compilation rule files are distinguished by pre-setting the first and second compilation macros, ensuring that the boot task configuration logic of different security levels can be isolated during the compilation phase.

[0126] First, the first and second compilation macros can be distinguished based on the compilation rules in the compilation rule file, i.e., forming a master core compilation rule file Master Makefile (first compilation rule file) and a slave core compilation rule file Slave Makefile (second compilation rule file). Further, based on different compilation rule files in combination with code, boot task configuration files corresponding to the master core and the slave core can be generated, realizing hierarchical scheduling and task isolation of hardware resources.

[0127] In some examples, in combination with the first compilation rule file and the code library corresponding to the first-level boot phase, a first-level boot task configuration file corresponding to the first-level boot phase can be formed. In combination with the first compilation rule file and the code library corresponding to the second-level boot phase, a second-level boot task configuration file can be formed. In combination with the second compilation rule file and the code library corresponding to the second-level boot phase, a second boot task configuration file can be formed.

[0128] Among them, the second-level boot task configuration file and the second boot task configuration file can be compiled based on the same code library, thereby realizing the separation of security levels through differentiated compilation macro definitions, while retaining the consistency of function implementation, thereby improving development efficiency and code reuse rate under the premise of ensuring system security. Through static configuration isolation during compilation, it is ensured that high-security-level tasks are not affected by low-security-level modules, while meeting the flexible deployment requirements in multiple scenarios.

[0129] In some embodiments, a boot starting method is also provided, which can be applied to the display device 200, the method comprising: In response to the start-up instruction, the first start-up task configuration file is loaded into the memory by the main core; The first start-up task is executed by the main core based on the first start-up task configuration file; The slave core is woken up by the main core when the first start-up task is executed to a preset stage; The second start-up task configuration file is loaded into the memory by the slave core; The second start-up task is executed by the slave core based on the second start-up task configuration file; wherein the security level of the second start-up task is lower than that of the first start-up task; the second start-up task and the remaining first start-up task are executed in parallel.

[0130] The similar parts among the embodiments provided in the application can be referred to each other, the specific embodiments provided above are only several examples under the general concept of the application, and do not constitute the limitation of the protection scope of the application. For those skilled in the art, any other embodiments extended according to the application scheme without creative labor are within the protection scope of the application.

Claims

1. A display device, characterized by comprising: The application relates to a display device, which comprises a display, a controller, a memory and a slave core. The controller comprises a master core and a slave core. The master core is configured to: load a first boot task configuration file into a memory in response to a boot instruction; execute a first boot task based on the first boot task configuration file; the first boot task comprises a primary boot task and a secondary boot task; the security level of the secondary boot task is lower than that of the primary boot task; wake up the slave core when the execution of the primary boot task in the first boot task is completed. The slave core is configured to: load a second boot task configuration file into a running memory after being woken up by the master core; execute a second boot task based on the second boot task configuration file; the security level of the second boot task is lower than that of the first boot task; the second boot task is executed in parallel with the secondary boot task. The application further relates to a display device, which comprises a memory.

2. The display device of claim 1, wherein, The first memory is used for storing task configuration files corresponding to non-upgradable tasks, and the second memory is used for storing task configuration files corresponding to upgradable tasks; the first boot task comprises a primary boot task and a secondary boot task; the master core executes the first boot task based on the first boot task configuration file, and is specifically configured to: load the primary task configuration file from the first memory into the running memory in response to a boot instruction; execute the primary boot task based on the primary task configuration file; load the secondary task configuration file from the second memory into the running memory after the execution of the primary boot task is completed; execute the secondary boot task based on the secondary task configuration file. The slave core executes the second boot task based on the second boot task configuration file, and is specifically configured to: load the second boot task configuration file from the second memory into the running memory; the second boot task configuration file is stored in a storage space different from that of the secondary task configuration file in the second memory.

3. The display device of claim 2, wherein, The second boot task comprises starting a customized function; the secondary boot task at least comprises configuring a bottom-layer driver of the customized function; the master core executes the secondary boot task based on the secondary task configuration file, and is specifically configured to: read a customized function identifier through a preset interface; 4. The display device of claim 3, wherein, configure a bottom-layer driver corresponding to the customized function based on a bottom-layer driver parameter in the secondary task configuration file when the customized function identifier represents that the customized function has not been started; send a configuration message to the slave core, and the configuration message is used for representing that the configuration of the bottom-layer driver corresponding to the customized function is completed. The slave core executes the second boot task based on the second boot task configuration file, and is specifically configured to: read the customized function identifier bit through the preset interface; 5. The display device of claim 4, wherein, listen to the configuration message when the customized function identifier bit represents that the customized function has not been started; set the customized function identifier to a starting identifier when the configuration message is received. ​ ​ 6. The display device of claim 4, wherein, The master core is further configured to: If the customized function identifier is not read within a preset time, a reset instruction is generated; the reset instruction is used to instruct the display device to restart the boot process.

7. The display device of claim 2, wherein, The master core is further configured to: The master core is further configured to:

8. The display device of claim 7, wherein, The master core is further configured to: The running identifier bit corresponding to the slave core is modified; the running identifier bit is used to indicate the task execution type of the slave core. The slave core is further configured to: The running identifier bit is read; The second boot task configuration file is loaded based on the running identifier bit.

9. A method for generating a boot configuration file, characterized in that, Comprising: A first compilation macro and a second compilation macro are set in a compilation rule file; the first compilation macro is used to indicate a compilation rule that can generate a first compilation rule file, the first compilation rule file is used to indicate a first to-be-compiled code that can generate a first boot task configuration file, and the first boot task configuration file is used to execute a first boot task; the second compilation macro is used to indicate a compilation rule that can generate a second compilation rule file, the second compilation rule file is used to indicate a second to-be-compiled code that can generate a second boot task configuration file, and the second boot task configuration file is used to execute a second boot task; the security level of the second boot task is lower than that of the first boot task; The first compilation rule file and the second compilation rule file are generated according to the compilation rule file, the first compilation macro, and the second compilation macro; A first boot task configuration file is generated based on a first code library and the first compilation rule file; The first boot task configuration file corresponds to a non-upgradable task; A second boot task configuration file is generated based on a second code library and the first compilation rule file; The second boot task configuration file corresponds to an upgradable task; A second boot task configuration file is generated based on the second code library and the second compilation rule file.

10. A method of starting up a computer, characterized by Comprising: In response to a boot instruction, a first boot task configuration file is loaded into a running memory by a master core; A first boot task is executed by the master core based on the first boot task configuration file; The slave core is woken up by the master core when the first boot task reaches a preset stage; A second boot task configuration file is loaded into the running memory by the slave core; A second boot task is executed by the slave core based on the second boot task configuration file; the security level of the second boot task is lower than that of the first boot task; and the second boot task and the remaining first boot task are executed in parallel.

Images