FPGA firmware upgrading method and related equipment

Abstract

The invention discloses an FPGA (Field Programmable Gate Array) firmware upgrading method and related equipment. According to the method, under the condition that FPGA firmware upgrading needs to be carried out, the electronic equipment can switch the state of the state machine to the upgrading state, lock protection is carried out on the switching process, the currently-used FPGA firmware can be erased, and the new FPGA firmware can be burnt and applied. In the erasing, burning and application process, when the level of the GPIO pin used for simulating the JTAG needs to be set, the electronic equipment can write the register preset value corresponding to the target level of the GPIO pin into the corresponding register, and maintenance and measurement information related to register access does not need to be recorded. According to the method, time consumed in the FPGA firmware upgrading process can be saved, so that the JTAG working frequency simulated through GPIO is improved, the requirement of the JTAG working frequency achieved by hardware is met, and hot updating of the FPGA firmware is achieved.

Description

Technical Field

[0001] This application relates to the field of communications, and in particular to an FPGA firmware upgrade method and related equipment. Background Technology

[0002] When different Original Equipment Manufacturers (OEMs) use the same Central Processing Unit (CPU) solution (e.g., Qualcomm), they often build differentiated features at the board-level hardware level to enhance product competitiveness. Furthermore, leveraging the ability of Field Programmable Gate Arrays (FPGAs) to modify internal hardware functions through in-system programming, the first few generations of these hardware differentiation features are typically implemented on FPGA devices (referred to as FPGAs) to accelerate time-to-market, significantly shortening development cycles.

[0003] However, whether it is software or hardware, although it will undergo a lot of testing before the product reaches the user, there will inevitably be some unknown problems. For example, in some extreme scenarios, it may trigger functional failure or even system crash. Of course, there may also be some major feature updates later. These require OEM manufacturers to have the ability to remotely update the hardware configuration files (referred to as firmware) of the FPGAs already deployed on the user side. Summary of the Invention

[0004] This application provides an FPGA firmware upgrade method and related equipment. This method can reduce the simulated JTAG cycle time by reducing the time consumed during the firmware upgrade process other than hardware time, thereby increasing the simulated JTAG operating frequency to meet the JTAG standard operating frequency defined by the hardware specifications, so as to smoothly realize hot updates of FPGA firmware.

[0005] Firstly, this application provides an FPGA firmware upgrade method. This method can be applied to an electronic device including an FPGA device and multiple GPIO pins. The method may include: the electronic device receiving a first FPGA firmware sent by a cloud-side server; upon confirmation of the upgrade and the first FPGA firmware meeting a first preset condition, the electronic device controlling M GPIO pins among the multiple GPIO pins to simulate JTAG signal lines to upgrade the FPGA device's firmware to the first FPGA firmware. M is a positive integer. During the upgrade process, the electronic device maintains the simulated JTAG operating frequency in accordance with the JTAG standard operating frequency defined by the hardware specifications.

[0006] In the solution provided in this application, an electronic device can simulate a JTAG interface using M GPIO pins. The voltage levels of these M GPIO pins correspond to the JTAG signal line voltage levels, enabling the transmission of simulated JTAG commands to the FPGA via these M GPIO pins for firmware upgrades. Furthermore, during the firmware upgrade process, the electronic device maintains the simulated JTAG operating frequency in accordance with the hardware-defined JTAG standard operating frequency. Through this method, the electronic device can control the GPIO-simulated JTAG operating frequency to meet the requirements of the hardware-implemented JTAG operating frequency, thus facilitating hot updates to the FPGA firmware—that is, updating the FPGA firmware without affecting user operation.

[0007] In conjunction with the first aspect, in one possible implementation, the M GPIO pins may include a first GPIO pin. The electronic device controls the M GPIO pins among the plurality of GPIO pins to simulate JTAG signal lines to upgrade the firmware of the FPGA device to the first FPGA firmware. Specifically, this may include: the electronic device controlling the M GPIO pins to simulate JTAG signal lines to erase the original FPGA firmware, program the first FPGA firmware onto the FPGA device, and apply the first FPGA firmware to the FPGA device. During the process of erasing the original FPGA firmware, programming the first FPGA firmware onto the FPGA device, and applying the first FPGA firmware, if it is necessary to set the level of the first GPIO pin to a target level, the electronic device can write a first preset value into a first register. The first preset value is a preset value of the GPIO register corresponding to the target level, where the target level is either high or low. The first register is the register corresponding to the first GPIO pin.

[0008] It is understandable that the first GPIO pin can be any GPIO pin used to simulate the JTAG interface, that is, any one of the M GPIO pins. During FPGA firmware upgrades via these M GPIO pins, the electronic device needs to simulate JTAG commands (e.g., JTAG write commands, JTAG write data, etc., mentioned below) and send them to the FPGA device so that the FPGA device can receive and respond to the JTAG commands in a timely manner. Specifically, the electronic device can determine the level of the JTAG signal line corresponding to the JTAG command to be simulated based on the JTAG protocol, and simulate the level change of the JTAG signal line by setting the levels of the M GPIO pins. Thus, after the levels of the M GPIO pins are set, the FPGA device connected to the M GPIO pins can sense the level changes of the M GPIO pins and respond to the JTAG commands corresponding to the level changes of the M GPIO pins.

[0009] In the solution provided in this application, the electronic device can set preset values ​​for the registers corresponding to the M GPIO pins. Specifically, it sets a preset value for a high level (i.e., the GPIO register preset value corresponding to the high level mentioned in this application) and a preset value for a low level (i.e., the GPIO register preset value corresponding to the low level mentioned in this application). Thus, during FPGA firmware upgrades, for the GPIO pins among the M GPIO pins that require level settings, the electronic device does not need to read back the original register value. Instead, it can directly write the GPIO register preset value corresponding to the target level of the GPIO pin to the GPIO register corresponding to that pin. This saves the time spent reading back the original register value before writing to the GPIO register, thereby reducing the level switching cycle when the electronic device simulates JTAG via GPIO (i.e., the JTAG working cycle mentioned in this application, which can be simply referred to as the working cycle). This increases the JTAG working frequency simulated via GPIO, thus meeting the requirements of the hardware-implemented JTAG working frequency, enabling smooth hot updates to the FPGA firmware.

[0010] It should also be noted that, on the one hand, for GPIO pins used to simulate the JTAG interface that require level settings, electronic devices can directly write the preset value of the GPIO register corresponding to the target level into the corresponding GPIO register, thereby reducing the JTAG duty cycle. On the other hand, electronic devices can control the JTAG duty cycle to ensure that the simulated JTAG operating frequency conforms to the JTAG standard operating frequency defined by the hardware specifications. For example, electronic devices can increase the JTAG duty cycle by increasing the level switching period of the simulated JTAG clock signal line, while keeping the JTAG operating frequency in line with the JTAG standard operating frequency, so that the JTAG operating frequency does not exceed the JTAG standard operating frequency due to directly writing the preset value of the GPIO register.

[0011] In some embodiments of this application, the first register may be one of the GPIO registers mentioned below.

[0012] In conjunction with the first aspect, in one possible implementation, during the process of upgrading the firmware of the FPGA device to the first FPGA firmware, when setting the level for any one or more of the M GPIO pins, the electronic device may not store the maintenance information related to accessing the registers corresponding to the M GPIO pins.

[0013] In the solution provided in this application, the electronic device does not need to record maintenance information (hereinafter referred to as maintenance data related to accessing the GPIO register) related to accessing the registers corresponding to the GPIO pins used to simulate the JTAG interface (e.g., reading / writing the registers corresponding to the GPIO pins used to simulate the JTAG interface). This saves the time spent storing maintenance information during the GPIO register access process, thereby reducing the level switching cycle when the electronic device simulates JTAG via GPIO, thus increasing the JTAG operating frequency simulated via GPIO, and enabling it to meet the requirements of the hardware-implemented JTAG operating frequency, so as to smoothly achieve hot updates for FPGA firmware. Furthermore, the maintenance information related to the GPIO register is information stored mainly to assist in testing bus hang-up issues in the general process of accessing device registers. However, in the solution provided in this application, the power and clock are always provided when accessing the GPIO register, and the aforementioned bus hang-up issues will not exist. Therefore, the electronic device not storing maintenance information will not affect FPGA firmware upgrades.

[0014] It should also be noted that, on the one hand, electronic devices do not need to record and access the monitoring information related to the registers corresponding to the GPIO pins used to simulate the JTAG interface, thereby reducing the JTAG duty cycle. On the other hand, electronic devices can control the JTAG duty cycle so that the simulated JTAG operating frequency conforms to the JTAG standard operating frequency defined by the hardware specifications. For example, electronic devices can increase the JTAG duty cycle by increasing the level switching period of the simulated JTAG clock signal line, while keeping the JTAG operating frequency in line with the JTAG standard operating frequency, so that the JTAG operating frequency does not exceed the JTAG standard operating frequency due to not storing and accessing the monitoring data related to the GPIO registers.

[0015] In conjunction with the first aspect, in one possible implementation, the electronic device may further include a state machine. Before the electronic device controls M GPIO pins out of the plurality of GPIO pins to simulate JTAG signal lines to upgrade the firmware of the FPGA device to a first FPGA firmware, the method may further include: upon confirmation of the upgrade and that the first FPGA firmware meets a first preset condition, the electronic device may switch the state of the state machine to a first state, and the process of switching to the first state is protected by a lock. Wherein, when the state machine is in the first state, the electronic device is in the process of upgrading the firmware of the FPGA device through an upgrade interface. This upgrade interface is an interface simulated by the electronic device through the M GPIO pins.

[0016] In the solution provided in this application, the electronic device can set up a state machine and a state machine lock for FPGA firmware upgrade. In other words, the electronic device can move the lock protection before writing registers to prevent concurrent register operations to the business layer. That is, the state machine ensures that only one upgrade operation is performed at a time, and the state machine switching is protected by a state machine lock to prevent other instructions from affecting the state machine switching. This reduces the number of time-consuming lock protection operations for writing registers during the firmware upgrade process to lock protection operations that only require a single state switch.

[0017] In some embodiments of this application, the first state may be the upgrade state mentioned below.

[0018] In some embodiments of this application, the electronic device switches the state of the state machine to a first state, and the process of switching to the first state is protected by a lock. Specifically, this may include: when the state machine lock is acquired, the electronic device switches the state of the state machine to the first state; when the state machine has been switched to the first state, the electronic device may release the state machine lock.

[0019] It should also be noted that, on the one hand, the electronic device only needs to perform a lock protection operation once when switching states, without having to perform a large number of time-consuming lock protection operations for writing registers, which can reduce the JTAG duty cycle. On the other hand, the electronic device can control the JTAG duty cycle so that the simulated JTAG operating frequency conforms to the JTAG standard operating frequency defined by the hardware specifications. For example, the electronic device can increase the JTAG duty cycle by increasing the level switching period of the simulated JTAG clock signal line, while keeping the JTAG operating frequency in line with the JTAG standard operating frequency, so that the JTAG operating frequency does not exceed the JTAG standard operating frequency due to the aforementioned lock protection operation when switching states only once.

[0020] In conjunction with the first aspect, in one possible implementation, the electronic device switches the state machine to a first state. Specifically, this can include: if the state machine is in a second state, the electronic device can switch the state machine from the second state to the first state; if the state machine is in a third state, it needs to wait until the state machine becomes the second state before switching the state machine to the first state. When the state machine is in the second state, the electronic device is not in the process of configuring the FPGA device through the control interface; while when the state machine is in the third state, the electronic device is in the process of configuring the FPGA device through the control interface.

[0021] In the solution provided in this application, the electronic device can switch the state machine to the upgrade state only when it is not in the process of configuring the FPGA device through the control interface. That is, it provides an upgrade interface to upgrade the FPGA firmware. This ensures that the FPGA firmware upgrade can be achieved without affecting the processor configuration of the FPGA device in the electronic device.

[0022] In some embodiments of this application, the second state may be the idle state mentioned below, and the third state may be the running state mentioned below.

[0023] In some embodiments of this application, the electronic device may reuse the same GPIO pins as both the control interface and the upgrade interface. In still other embodiments, the electronic device may use different GPIO pins as both the control interface and the upgrade interface.

[0024] In conjunction with the first aspect, in one possible implementation, after the electronic device switches the state machine to the first state, the method may further include: the electronic device can switch the operating mode of the FPGA device to the first mode by setting the levels of N GPIO pins out of a plurality of GPIO pins. When the FPGA device is operating in the first mode, the FPGA device can perform firmware upgrades through an upgrade interface. N is a positive integer.

[0025] In the solution provided in this application, after the electronic device realizes the state switching at the software level, it can realize the switching of the FPGA device hardware mode, that is, switch the FPGA working mode to the firmware upgrade mode, so that the FPGA device can successfully receive and respond to JTAG commands through the upgrade interface.

[0026] In some embodiments of this application, the first mode is the firmware upgrade mode mentioned below.

[0027] In some embodiments of this application, the N GPIO pins are partially the same as or completely identical to the M GPIO pins.

[0028] In some other embodiments of this application, the N GPIO pins are completely different from the M GPIO pins.

[0029] In conjunction with the first aspect, in one possible implementation, after the electronic device upgrades the firmware of the FPGA device to the first FPGA firmware, the method may further include: the electronic device can switch the state of the state machine to a second state; the electronic device can switch the operating mode of the FPGA device to the second mode by setting the level of N GPIO pins among the plurality of GPIO pins. When the operating mode of the FPGA device is the second mode, the FPGA device does not perform firmware upgrades through the upgrade interface.

[0030] In the solution provided in this application, after the electronic device completes the FPGA firmware upgrade, the hardware mode of the FPGA device can be switched to the runtime mode to avoid affecting the electronic device's configuration of the FPGA through the processor (which can be understood as other interactions besides firmware upgrade).

[0031] In some embodiments of this application, the second mode is the runtime mode mentioned below.

[0032] It is understandable that when the FPGA device is operating in the second mode, the FPGA device does not achieve firmware upgrade through the upgrade interface. This can mean that the electronic device does not provide an upgrade interface, and the FPGA cannot achieve firmware upgrade through the upgrade interface.

[0033] In conjunction with the first aspect, in one possible implementation, before the electronic device receives the first FPGA firmware sent by the cloud-side server, the method may further include:

[0034] In response to the operation of activating the electronic device, the electronic device can perform the following initialization processes:

[0035] Obtain the M GPIO pins used to simulate JTAG signal lines and initialize them;

[0036] Obtain the N GPIO pins used to control the operating mode of the FPGA device and initialize them;

[0037] Initialize the state machine and state machine lock, and set the state machine's state to the second state;

[0038] Obtain and initialize the clock and power supply of the FPGA device.

[0039] In the solution provided in this application, when the electronic device starts up, the modules related to FPGA firmware upgrade can be initialized, so that after the electronic device receives the first FPGA firmware sent by the cloud server, it can quickly respond and perform FPGA firmware upgrade.

[0040] In conjunction with the first aspect, in one possible implementation, during the firmware upgrade of the FPGA device to the first FPGA firmware, the electronic device maintains the simulated JTAG operating frequency in accordance with the JTAG standard operating frequency defined in the hardware specifications. Specifically, this may include: during the firmware upgrade of the FPGA device to the first FPGA firmware, adding a first delay to the current duty cycle to obtain an updated duty cycle. The updated duty cycle is the reciprocal of the target operating frequency. The target operating frequency conforms to the JTAG standard operating frequency defined in the hardware specifications.

[0041] In the solution provided in this application, the electronic device can control the JTAG duty cycle so that the simulated JTAG operating frequency conforms to the JTAG standard operating frequency defined by the hardware specifications. For example, in order to avoid the JTAG operating frequency exceeding the JTAG standard operating frequency due to a significant reduction in the JTAG duty cycle, the electronic device can increase the level switching period of the simulated JTAG clock signal line by increasing the delay, thereby increasing the JTAG duty cycle and keeping the JTAG operating frequency conforming to the JTAG standard operating frequency.

[0042] In some embodiments of this application, the first delay may be the delay determined based on the target operating frequency, as mentioned below.

[0043] In a second aspect, this application provides an electronic device including an FPGA device, one or more memories, and one or more processors; the FPGA device and the one or more memories may be coupled to the one or more processors, the memories being used to store computer program code including computer instructions, the processor including a plurality of GPIO pins being used to simulate JTAG signal lines, and the computer instructions being invoked to cause the electronic device to perform the method described in the first aspect or any implementation thereof.

[0044] In some embodiments of this application, the processor can configure the operating mode of the FPGA device through the multiple GPIO pins. In still other embodiments of this application, the processor can switch the operating mode of the FPGA device through the multiple GPIO pins.

[0045] Thirdly, this application provides a computer storage medium. The computer storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect or any implementation thereof.

[0046] Fourthly, embodiments of this application provide a chip. This chip can be applied to an electronic device, and the chip includes one or more processors. The processors are used to invoke computer instructions to cause the electronic device to perform the methods described in the first aspect or any implementation thereof.

[0047] Fifthly, embodiments of this application provide a chip system. This chip system can be applied to an electronic device. The chip system includes at least one processor and an interface for receiving instructions and transmitting them to the at least one processor; the at least one processor executes the received instructions, causing the electronic device to perform the method described in the first aspect or any implementation thereof.

[0048] In some embodiments of this application, the chip system may be an application processor (AP) or a system on chip (SoC) including an AP, and the method described in the first aspect or any implementation thereof may be implemented by an AP.

[0049] In some other embodiments of this application, the chip system may include an access point (AP) and other modules. These other modules may be a modem (also known as a baseband processor).

[0050] Sixthly, embodiments of this application provide a computer program product including instructions. When the computer program product is run on an electronic device, it causes the electronic device to perform the method described in the first aspect or any implementation thereof.

[0051] It is understood that the electronic device provided in the second aspect, the computer storage medium provided in the third aspect, the chip provided in the fourth aspect, the chip system provided in the fifth aspect, and the computer program product provided in the sixth aspect are all used to execute the method described in the first aspect or any implementation thereof. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of any possible implementation of the first aspect, which will not be repeated here. Attached Figure Description

[0052] Figure 1 This is a schematic diagram illustrating a scenario where an OEM pushes FPGA firmware to the end side for hot updates, as provided in an embodiment of this application.

[0053] Figure 2 A schematic diagram of a level switching cycle provided in an embodiment of this application;

[0054] Figure 3 This is another schematic diagram of a level switching cycle provided in an embodiment of this application;

[0055] Figure 4 A flowchart for setting GPIO levels is provided as an embodiment of this application;

[0056] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0057] Figure 6 A schematic diagram of the user space and kernel space of an electronic device provided in an embodiment of this application;

[0058] Figure 7 A flowchart illustrating an FPGA firmware upgrade method provided in this application embodiment;

[0059] Figure 8 A schematic diagram of software and hardware interaction provided for an embodiment of this application;

[0060] Figures 9A-9C A flowchart illustrating yet another FPGA firmware upgrade method provided in this application embodiment;

[0061] Figure 10A A flowchart illustrating a JTAG state switching method provided in this application embodiment;

[0062] Figure 10B A flowchart illustrating a method for simulating JTAG write commands, provided as an embodiment of this application;

[0063] Figure 10C A flowchart for entering the JTAG runtime test state is provided as an embodiment of this application;

[0064] Figure 10D A flowchart illustrating a method for simulating JTAG data writing, provided as an embodiment of this application;

[0065] Figure 10E A flowchart illustrating a method for simulating JTAG data reading provided in an embodiment of this application. Detailed Implementation

[0066] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0067] It should be understood that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0068] It should be understood that the term "user interface" in the specification, claims, and drawings of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be an icon, window, control, or other interface element displayed on the screen of an electronic device. Controls can include visual interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets.

[0069] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0070] First, some of the terms and related technologies used in this application will be explained to facilitate understanding by those skilled in the art.

[0071] 1. FPGA

[0072] As mentioned above, because FPGAs allow for in-circuit programming to modify their internal hardware functions, defects in the internal hardware can be quickly fixed by redeploying the FPGA configuration, significantly shortening the development cycle. Based on this characteristic of FPGAs, different OEMs can use them to build differentiated features at the board-level hardware level. Furthermore, to address the need for subsequent feature updates, resolving functional failures, or system crashes, OEMs need the ability to remotely update the firmware of FPGAs already deployed on the user's side.

[0073] It is understandable that FPGA is a further development based on programmable devices such as PAL (Programmable Array Logic) and GAL (General Purpose Array Logic). It emerged as a semi-custom circuit in the field of Application-Specific Integrated Circuits (ASICs), addressing the shortcomings of custom circuits while overcoming the limited gate count of earlier programmable devices. FPGA employs the concept of a Logic Cell Array (LCA), which internally comprises three parts: Configurable Logic Blocks (CLBs), Input / Output Blocks (IOBs), and interconnects. Field-Programmable Gate Arrays (FPGAs) are programmable devices.

[0074] 2. JTAG

[0075] Currently, common FPGA firmware upgrade protocols typically include the Joint Test Action Group (JTAG) protocol. However, the processors of electronic devices such as mobile phones and tablets (or terminals) usually do not have hardware JTAG controllers. Therefore, it is necessary to control the General Purpose Input / Output Port (GPIO) pins through the processor to simulate the standard JTAG protocol, thereby achieving firmware upgrades. Furthermore, to minimize the impact of FPGA firmware upgrades on normal user operation, electronic devices can use hot upgrades (i.e., upgrades that do not require the user to restart the phone) to perform FPGA firmware upgrades. In this case, the electronic device needs to perform the FPGA firmware upgrade in a boot-up environment (e.g., the Android operating environment).

[0076] like Figure 1 As shown, to address the needs of fixing high-risk security vulnerabilities related to FPGAs, fixing FPGA-related issues affecting system stability, and introducing performance improvements and new features, OEMs can push new FPGA firmware to the device side for hot updates via a cloud server. Specifically, the device side (the electronic device mentioned above) can control the GPIO pins by running software in the SoC to read and write registers in the GPIO controller, thereby simulating the JTAG protocol and updating the original FPGA firmware to the new FPGA firmware.

[0077] As is understandable, JTAG is an international standard testing protocol primarily used for internal chip testing. It conforms to the IEEE 1149.1 standard and is the standard interface for most advanced devices, such as Digital Signal Processors (DSPs), FPGAs, Advanced Reduced Instruction Set Computers (ARM), and some microcontrollers. The JTAG interface includes four basic signal lines: TMS (Mode Select), TCK (Clock), TDI (Data Input), and TDO (Data Output). Furthermore, JTAG is not only used for testing but also as a communication protocol, allowing direct control and reading / writing of the CPU's program—a relatively rare low-level control method among other communication protocols.

[0078] It's important to note that different FPGA vendors impose hardware specifications on the JTAG operating frequency range during firmware upgrades. For example, the domestic FPGA vendor Gowin states in its product specifications that "operations on the built-in FLASH include erase, erase and program, as well as erase, program, and verify operations. The built-in FLASH can only be operated via the JTAG interface, with a clock rate limited to 2MHz to 2.5MHz," thus limiting the minimum operating frequency for updating FPGA firmware via the JTAG interface to 2 MHz. However, when electronic devices simulate the JTAG protocol by controlling GPIO pins through the processor (which can be simply referred to as controlling GPIO to simulate JTAG), their operating frequency typically cannot reach the hardware-implemented JTAG operating frequency. For instance, the level switching period of the native GPIO level setting interface (gpiod_set_value) on the Qualcomm platform, captured by a logic analyzer, is greater than 10 microseconds (µs), meaning the level switching period when an electronic device simulates JTAG via GPIO is less than 10µs. Figure 2 The level switching period shown is 10.42µs or 10.8µs, indicating that the maximum operating frequency of JTAG simulated by the electronic device via GPIO is less than 100 kHz, which is much lower than the operating frequency of the hardware-implemented JTAG. This also means that existing electronic devices cannot support hot updates of FPGA firmware.

[0079] Furthermore, by breaking down the time consumed in setting (or switching) GPIO levels using the Android native GPIO level setting interface (gpiod_set_value), it was found that the hardware time consumed in calling the Android native GPIO level setting interface to set GPIO levels (i.e., the level of GPIO pins) can meet the lower limit requirement of the simulated JTAG operating frequency.

[0080] For example, Figure 3This illustrates the pure hardware time required to set GPIO levels by calling the Android native GPIO level setting interface. For example... Figure 3 As shown, the hardware latency required to set the GPIO level is in the nanosecond range. This indicates that the hardware latency of calling the Android native GPIO level setting interface to set the GPIO level meets the lower limit requirement of the simulated JTAG operating frequency. For example, Figure 3 The longest level switching cycle is the sum of 50 nanoseconds (ns) and 150 ns, which is 200 ns. The corresponding level switching frequency is 5 MHz, which is greater than the minimum operating frequency of the hardware-implemented JTAG.

[0081] Furthermore, consider whether there are other time-consuming factors besides hardware time consumption that could cause the JTAG operating frequency simulated by GPIO to fail to meet the corresponding hardware specifications.

[0082] For example, Figure 4 This demonstrates the process of setting GPIO levels by calling the Android native GPIO level setting interface. For example... Figure 4As shown, setting the GPIO level of an electronic device includes the following steps: (1) calling the native Android GPIO level setting interface, i.e., gpiod_set_value; (2) the native Android GPIO level setting interface further calls the corresponding interface to perform some rationality checks; (3) the native Android GPIO level setting interface further calls the GPIO level setting interface of the corresponding platform, such as the GPIO level setting interface provided by the Qualcomm platform, i.e., msm_gpio_set; (4) the GPIO level setting interface of the corresponding platform further calls the interface (e.g., raw_spin_lock_irqsave) to acquire the lock; (5) the GPIO level setting interface of the corresponding platform further calls the read device register encapsulation interface, such as msm_readl_io; (6) the read device register encapsulation interface further calls the native read device register interface, i.e., readl; (7) store (8) Read back the original value of the GPIO register through the native read device register interface; (9) Update the configuration value of the corresponding position of the GPIO register based on the level configuration value through the GPIO level setting interface of the corresponding platform to obtain the new GPIO register configuration value; (10) The GPIO level setting interface of the corresponding platform further calls the write device register encapsulation interface, such as msm_writel_io; (11) The write device register encapsulation interface further calls the native write device register interface, i.e. writel; (12) Store the maintenance information related to the write device register operation; (13) Write the value of the GPIO register to the above new GPIO register configuration value through the native write device register interface; (14) The GPIO level setting interface of the corresponding platform further calls the interface (e.g., raw_spin_unlock_irqrestore) to release the lock. Of these, step (2) has almost no impact on the time consumption, while steps (4), (6), (7), and (12) require additional time of more than microseconds, and step (13) is the necessary hardware consumption. It is understandable that the time consumption of steps (4), (6), (7), and (12) is the main factor affecting the JTAG operating frequency of GPIO simulation, apart from the hardware consumption.

[0083] `raw_spin_lock_irqsave` is a native interface provided by the Linux kernel, a spin lock among lock interfaces used for concurrency protection. It can also be used to disable local CPU interrupts, protecting concurrent resource operations in process context and interrupt context. `raw_spin_unlock_irqrestore` is a spin lock unlocking interface provided by the Linux kernel; its function is to release a spin lock previously acquired through `raw_spin_lock_irqsave` and restore the processor's interrupt state to its previously saved state. `msm_readl_io` is a wrapper around the kernel's native `readl` interface, making it easier to read GPIO registers. `readl` is the kernel's native interface for reading memory-mapped I / O space data; simply put, it's an interface for reading device registers. Similarly, `msm_writel_io` is a wrapper around the kernel's native `writel` interface, making it easier to write to GPIO registers. `writel` is the kernel's native interface for writing memory-mapped I / O space data; simply put, it's an interface for writing device registers.

[0084] Based on the above, this application provides an FPGA firmware upgrade method and related equipment. According to this method, the electronic device can be equipped with a state machine and a state machine lock for FPGA firmware upgrades, and preset values ​​are set for the registers corresponding to the GPIO pins used to simulate the JTAG protocol. When a new FPGA firmware is received from the cloud and its version number is determined to be higher than the version number of the currently used FPGA, the electronic device can acquire the state machine lock, switch the state machine to the upgrade state, and then release the state machine lock. Further, the electronic device can erase the currently used FPGA firmware and program the new FPGA firmware. During the erasure and programming process, the electronic device can perform register write operations using the preset values ​​set for the registers corresponding to the GPIO pins used to simulate JTAG. The upgrade can be completed without subsequently recording maintenance information related to accessing the GPIO registers. This method can save time in the FPGA firmware upgrade process, such as the time spent on lock protection when writing to the GPIO register, the time spent reading back the original register value before writing to the GPIO register, and the time spent storing maintenance information during the GPIO register writing process. This can reduce the level switching cycle when the electronic device simulates JTAG through GPIO, thereby increasing the operating frequency of JTAG simulated through GPIO, and thus making it meet the requirements of the hardware-implemented JTAG operating frequency, so as to smoothly realize hot updates for FPGA firmware.

[0085] It is understood that the JTAG protocol simulation via GPIO pins mentioned in this application can also be referred to as the JTAG interface simulation via GPIO pins. Since the JTAG interface consists of JTAG signal lines, the JTAG protocol simulation via GPIO pins mentioned in this application can also be referred to as the JTAG signal line simulation via GPIO pins.

[0086] The apparatus involved in the embodiments of this application will be introduced first below.

[0087] The electronic devices involved in this application can be terminal devices, specifically mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), or dedicated cameras (e.g., SLR cameras, point-and-shoot cameras), etc. The embodiments of this application do not impose any restrictions on the specific type of electronic devices.

[0088] The hardware structure of the electronic device involved in the embodiments of this application is described below.

[0089] Please see Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0090] like Figure 5 As shown, the electronic device may include: a processor, an FPGA device (hereinafter referred to as FPGA), an external memory interface, internal memory, a Universal Serial Bus (USB) interface, a charging management module, a power management module, a battery, antenna 1, antenna 2, a mobile communication module, a wireless communication module, a sensor module, buttons, a motor, an indicator, a camera, a display screen, an audio module, and a Subscriber Identity Module (SIM) card slot, etc. The audio module may include a speaker, a receiver, a microphone, a headphone jack, etc., and the sensor module may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an accelerometer, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

[0091] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. It is understood that the illustrated components can be implemented in hardware, software, or a combination of both. In some embodiments of this application, the electronic device may include more components than illustrated. For example, the electronic device may include other types of sensors. In still other embodiments of this application, the electronic device may include fewer components than illustrated, or combine some components, or split some components, or arrange different components. The interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device.

[0092] A processor may include one or more processing units, such as an application processor (AP), a modem (also known as a baseband processor), a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), and / or a neural network processing unit (NPU). The AP is responsible for running the operating system and applications. The modem is responsible for handling various communication protocols.

[0093] In some embodiments of this application, the processor may be a system on a chip (SoC). SoC may include a CPU and other devices, such as a GPU.

[0094] In some embodiments of this application, the FPGA may include flash memory (FLASH). FLASH is a non-volatile memory; data is not lost after power is off, but an erase operation is required for reprogramming. It is understood that the relevant description of the FPGA can be found above, and will not be repeated here. The relevant data of the FPGA may be stored in internal memory.

[0095] In some embodiments of this application, the FPGA may include Static Random-Access Memory (SRAM). It can be read and written at any time and is very fast, and is typically used as a temporary data storage medium for the operating system or other running programs.

[0096] The wireless communication function of an electronic device can be implemented through antenna 1, antenna 2, a mobile communication module, a wireless communication module, and a modem. The modem can interact with the base station through antennas (e.g., antenna 1, antenna 2, etc.). In some embodiments, antenna 1 of the electronic device is coupled to the mobile communication module, and antenna 2 is coupled to the wireless communication module, enabling the electronic device to communicate with networks and other devices through wireless communication technology.

[0097] Electronic devices can achieve display functions through GPUs, displays, and application processors.

[0098] A GPU is a microprocessor for image processing, connected to a display screen and an application processor. A GPU performs mathematical and geometric calculations for graphics rendering. A processor may include one or more GPUs, which execute program instructions to generate or modify display information. A display screen is used to display images, videos, etc. In some embodiments, an electronic device may include one or more displays screens.

[0099] A camera is used to capture still images or videos. An ISP (Image Signal Processor) processes the data fed back from the camera. Light is transmitted through the lens to the camera's photosensitive element, where the light signal is converted into an electrical signal. The camera's photosensitive element then transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. Electronic devices may include one or more cameras.

[0100] Internal memory may include one or more Random Access Memory (RAM) and one or more Non-Volatile Memory (NVM). RAM can be directly read and written by the processor and can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, as well as user and application data. NVM can also store executable programs and user and application data, and can be pre-loaded into RAM for direct processor access.

[0101] In some embodiments of this application, the code implementing the methods described in the embodiments of this application may be stored in non-volatile memory. During operation of the electronic device, the electronic device may load the executable code stored in the non-volatile memory into random access memory.

[0102] External memory interfaces can be used to connect to external non-volatile memory, thereby expanding the storage capacity of electronic devices.

[0103] Electronic devices can implement audio functions through audio modules, speakers, receivers, microphones, headphone jacks, and application processors.

[0104] The software structure of the electronic device involved in the embodiments of this application is described below.

[0105] Operating systems for electronic devices can adopt layered architectures, event-driven architectures, microkernel architectures, microservice architectures, or cloud architectures. This application primarily relates to the user space and kernel space in an electronic device's operating system. The following section uses the layered architecture of the Android operating system (which can be simply referred to as the Android system) as an example to provide a detailed description of the user space and kernel space of an electronic device.

[0106] First, let's introduce the concepts of user space and kernel space.

[0107] Virtual memory is divided into two parts by the operating system: kernel space and user space. Kernel space is the environment in which the operating system kernel runs, containing the core functions and services of the operating system. User space is the environment in which user programs run, containing user applications and services.

[0108] The kernel space has the highest privileges and can access all operating system resources, such as directly accessing and controlling hardware resources and executing privileged instructions. User space, on the other hand, has limited privileges; it can only perform simple calculations and cannot directly access system resources, such as hardware resources. It must instead make requests to the kernel through system call interfaces.

[0109] Kernel space and user space are separated in memory, each with its own address space. This isolates user data from system data, ensuring system stability and allowing control over access to both sets of data. It prevents user programs from arbitrarily accessing system data, thus protecting against accidental or malicious manipulation. The kernel space address space is typically fixed, while the user space address space can be dynamically allocated as needed.

[0110] Based on the above concepts, the following will combine... Figure 6 This application provides a detailed description of the user space and kernel space in the electronic device involved in the embodiments.

[0111] The user space of an electronic device may include an Over-The-Air Technology (OTA) engine, an FPGA firmware management service rc file, and an FPGA firmware management service.

[0112] The OTA engine receives FPGA firmware sent by the cloud-side OTA server. The OTA engine and the cloud-side OTA server form the pathway for OEMs to push FPGA firmware. The FPGA firmware management service rc file is a configuration file used to control the FPGA firmware management service; for example, the FPGA firmware management service rc file can be used to control the startup of the FPGA firmware management service. In some embodiments of this application, the FPGA firmware management service rc file refers to the rc file corresponding to the FPGA firmware management service. That is, the FPGA firmware management service rc file can include configuration parameters related to the FPGA firmware management service, and control the FPGA firmware management service based on these configuration parameters. The FPGA firmware management service is used to initiate FPGA firmware upgrades and also to write the FPGA firmware received by the OTA engine to the corresponding node in the kernel space, thereby triggering the FPGA firmware upgrade operation in the kernel space.

[0113] As you can understand, OTA (Over-The-Air) is a technology that transmits data packets to devices via a wireless network for software updates or data management. In Linux systems, the rc file (short for runcom) stores scripts and configuration files that need to be run at startup. These files are typically used to initialize or configure the environment in which programs run.

[0114] The kernel space of an electronic device can include an FPGA driver. An FPGA driver can include an initialization module, a state machine, an FPGA firmware upgrade service, an FPGA vendor firmware upgrade protocol module, a JTAG emulation module, and an acceleration module. Specifically, the FPGA driver is the driver corresponding to the FPGA; that is, the FPGA driver is used to drive the actual FPGA device.

[0115] The initialization module can be used to acquire and initialize GPIOs that simulate JTAG, acquire and initialize GPIOs that control FPGA operating mode switching, map the physical address of GPIO registers to virtual addresses, acquire and initialize FPGA power and clock, initialize state machines and state machine locks, and create FPGA firmware upgrade services.

[0116] A state machine can be used to maintain the operational state of the FPGA driver, ensuring that only one FPGA firmware upgrade operation is performed at a time, and employing a locking mechanism to protect state transitions. The state machine provides an interface for requesting state transitions. In some embodiments of this application, when an external module calls the state machine to implement state transitions, the state machine can internally perform operations such as acquiring the state machine lock, switching states, and releasing the state machine lock, without requiring the external module to first acquire the state machine lock and then call the state machine to implement the state transition.

[0117] The FPGA firmware upgrade service can be used to uniformly control the erasure of the original FPGA firmware, the burning of the new FPGA firmware and reconfiguration, and further call the corresponding interfaces of the firmware upgrade protocol of the FPGA vendor.

[0118] The FPGA vendor firmware upgrade protocol module supports the specific implementation of FPGA firmware upgrades, providing the erase, program, and reconfiguration interfaces required for FPGA firmware upgrades. It can also be used to protect the atomic operations specified in the protocol by disabling CPU interrupts (or simply, disabling interrupts). An FPGA driver may include firmware upgrade protocols from one or more FPGA vendors.

[0119] The JTAG emulation module can be used to control the CPU to combine operations of different GPIO high and low level changes to simulate the standard JTAG protocol.

[0120] The acceleration module can be used to directly write the preset value corresponding to the level to be set into the GPIO register when setting the GPIO level. Furthermore, after writing the preset value to the GPIO register, the acceleration module does not need to store maintenance information. In other words, the acceleration module is a software module that differs from the native Android GPIO level setting interface.

[0121] It should be noted that in the general process of accessing device registers, a maintenance testing method (i.e., a method for locating problems) is set up to address various issues. For example, the maintenance testing information mentioned in this application is information stored primarily to assist in testing bus hang-type problems in the general process of accessing device registers. Maintenance testing information refers to the trace events of device register read and write operations, including device register read start, device register read end, device register write start, and device register write end. This type of maintenance testing information is typically used to assist in testing bus hang-type problems caused by accessing device registers when the device is powered off or without a clock. However, in the solution of this application, when accessing GPIO registers, power and clock are always provided, and the aforementioned bus hang-type problems do not exist. Therefore, maintenance testing information is not very useful in this application, and the electronic device does not need to store this maintenance testing information when accessing GPIO registers.

[0122] As you can understand, trace events are simply statically inserted tracking points in the code. When trace events are enabled, relevant execution data is recorded every time these tracking points are accessed. This data can then be used to analyze the system.

[0123] It should be noted that the user space and kernel space in an electronic device may also include other modules, such as the kernel space may include other drivers, and this application does not limit this.

[0124] It should also be noted that the application provided Figure 6 The schematic diagrams of the user space and kernel space of the illustrated electronic device are merely examples and do not limit the specific module divisions within the user space and kernel space of the Android system. For details, please refer to the descriptions of the Android system software structure in conventional technologies. Furthermore, although this application uses the Android system as an example for illustration, its basic principles are equally applicable to electronic devices based on operating systems such as iOS or Windows.

[0125] The following describes an FPGA firmware upgrade method provided by an embodiment of this application.

[0126] The FPGA firmware upgrade method mentioned in the embodiments of this application can be applied to electronic devices, and the method may include, but is not limited to, the following steps:

[0127] S1: Receives the first FPGA firmware sent by the cloud server.

[0128] As mentioned above (see reference for details) Figure 1 (As described in the relevant description), to address needs such as fixing high-risk security vulnerabilities related to FPGAs, fixing FPGA-related issues affecting system stability, and introducing performance improvements and new features, OEMs can push new FPGA firmware to the device side via a cloud-side server (or cloud server). It is understood that this cloud-side server can be the OTA server mentioned in this application.

[0129] For ease of understanding and description, this application refers to the FPGA firmware pushed by the cloud server to the device as the first FPGA firmware. This means that, to address the aforementioned issues or introduce new features, the cloud server can send the first FPGA firmware to the electronic device. Correspondingly, the electronic device can receive the first FPGA firmware sent by the cloud server.

[0130] S2: Upon confirming the upgrade and that the first FPGA firmware meets the first preset condition, the M GPIO pins in the electronic device are controlled to simulate JTAG signal lines to upgrade the FPGA firmware to the first FPGA firmware. During the upgrade process, the JTAG operating frequency simulated through the M GPIO pins is maintained to conform to the JTAG standard operating frequency defined in the hardware specifications.

[0131] After receiving the first FPGA firmware sent by the OTA server, the electronic device can determine whether to perform an FPGA firmware upgrade and whether the received first FPGA firmware meets the first preset condition. If the electronic device determines to perform an FPGA firmware upgrade and the first FPGA firmware meets the first preset condition, the electronic device can control M GPIO pins to simulate JTAG signal lines, thereby controlling the FPGA and upgrading the firmware in the FPGA to the first FPGA firmware.

[0132] In some embodiments of this application, after the electronic device receives the first FPGA firmware sent by the OTA server, it can prompt the user to confirm whether to perform an FPGA firmware upgrade. For example, the OTA engine can trigger the electronic device to display a prompt box to prompt the user to confirm whether an FPGA firmware upgrade is needed. In this case, the electronic device receiving a specific touch event (e.g., a touch event for the confirmation button) indicates confirmation of the upgrade. Alternatively, the OTA engine can trigger the electronic device to prompt the user to confirm whether an FPGA firmware upgrade is needed through voice broadcast. In this case, the electronic device receiving a specific voice (e.g., a voice containing the words "confirm upgrade") indicates confirmation of the upgrade.

[0133] In some embodiments of this application, the M GPIO pins can be M GPIO pins controlled by the GPIO controller in an electronic device processor (e.g., a SoC). The electronic device can control the FPGA by setting the levels of these M GPIO pins to simulate the level changes of the JTAG signal lines. That is, the electronic device can simulate operations such as writing instructions, writing data, or reading data from the FPGA by setting the levels of these M GPIO pins.

[0134] In some embodiments of this application, the interface simulated by the M GPIO pins is the upgrade interface mentioned in this application.

[0135] It is understandable that the JTAG standard operating frequency defined in the hardware specifications can refer to the operating frequency specified by the FPGA vendor for operating the FPGA via the JTAG interface. For example, the 2MHz to 2.5MHz mentioned above. It is also understandable that the JTAG standard operating frequency defined in the hardware specifications may differ for different FPGA vendors.

[0136] Based on the above, the electronic device maintains the JTAG operating frequency simulated through the M GPIO pins in accordance with the JTAG standard operating frequency defined by the hardware specification. Specifically, this may include: the electronic device maintaining the JTAG operating frequency simulated through the M GPIO pins within the JTAG operating frequency range defined by the hardware specification.

[0137] In some embodiments of this application, the electronic device can switch the state machine to the upgrade state and lock the switching process when the upgrade is confirmed and the first FPGA firmware meets the first preset condition, and switch the FPGA's operating mode to the firmware upgrade mode. After the above switching is completed, the electronic device can erase the original FPGA firmware, program the first FPGA firmware, and apply the first FPGA firmware. Furthermore, during the erasure, programming, and application processes, the electronic device does not lock the operations that access GPIO registers (e.g., write operations to registers corresponding to the M GPIO pins), thereby reducing the time consumed by the FPGA firmware upgrade and enabling the electronic device to achieve a simulated JTAG operating frequency that meets the hardware specification's JTAG operating frequency.

[0138] In some embodiments of this application, locking the switching process for an electronic device can mean that the electronic device does not respond to other switching commands.

[0139] In some embodiments of this application, when it is necessary to set the level of the M GPIO pins during FPGA firmware upgrade, the electronic device can directly write the preset value of the GPIO register corresponding to the target level of the GPIO pin into the corresponding GPIO register. It is not necessary to wait for the value of the GPIO register to be read back and the value to be written to the GPIO register to be written into the GPIO register, thereby reducing the time consumption of FPGA firmware upgrade and enabling the electronic device to achieve the simulated JTAG operating frequency to reach the JTAG operating frequency defined by the hardware specification.

[0140] In some embodiments of this application, during the FPGA firmware upgrade process, the electronic device does not need to store the maintenance information for accessing the GPIO register, thereby reducing the time consumed by the FPGA firmware upgrade and enabling the electronic device to achieve a simulated JTAG operating frequency that meets the JTAG operating frequency defined by the hardware specifications.

[0141] In some embodiments of this application, during FPGA firmware upgrades, if the actual achievable operating frequency of the electronic device exceeds the JTAG standard operating frequency defined by the hardware specifications (e.g., exceeding the maximum JTAG operating frequency defined by the hardware specifications), the electronic device can adjust the actual simulated JTAG operating frequency according to the JTAG standard operating frequency (i.e., the target operating frequency mentioned in this application). For example, the electronic device can adjust the simulated JTAG operating frequency by adjusting the duration of the high and / or low levels of the TCK pin (e.g., increasing the delay mentioned below in this application).

[0142] It is understood that the JTAG standard operating frequency defined by the hardware specifications mentioned in this application can be any value in the range of JTAG operating frequencies defined by the hardware specifications, such as the minimum JTAG operating frequency or the maximum JTAG operating frequency defined by the hardware specifications, and this application does not impose any restrictions on it.

[0143] It is understood that the relevant descriptions of the first preset conditions and the state of the state machine can be found in the following text, and will not be elaborated here.

[0144] The following describes a specific implementation of the above embodiments.

[0145] Please see Figure 7 , Figure 7 This is a flowchart illustrating an FPGA firmware upgrade method provided in an embodiment of this application. This method can be applied to electronic devices and may include, but is not limited to, the following steps:

[0146] S101: Received the first FPGA firmware sent by the OTA server.

[0147] It is understood that the specific implementation of step S101 can be referred to the relevant description of step S1, and this application does not limit it.

[0148] S102: If the upgrade is confirmed and the first FPGA firmware meets the first preset condition, the state machine is switched to the upgrade state, and the switching process is protected by a lock.

[0149] After receiving the first FPGA firmware sent by the OTA server, the electronic device can determine whether the first FPGA firmware meets a first preset condition upon confirmation of the upgrade (e.g., user confirmation of the upgrade as mentioned in this application). If the first FPGA firmware meets the first preset condition, the electronic device can perform an FPGA firmware upgrade based on the first FPGA firmware. For example, the electronic device can switch the state machine to the upgrade state and adopt a locking mechanism to protect the switching process. That is, it protects the switching process from being affected by other instructions that switch the state machine. If the first FPGA firmware does not meet the first preset condition, the electronic device will not perform an FPGA firmware upgrade.

[0150] In some embodiments of this application, the first FPGA firmware satisfies a first preset condition, which may specifically include: the first FPGA firmware passes integrity verification, and the version of the first FPGA firmware is newer than the version of the original FPGA firmware. In this case, the first FPGA firmware does not satisfy the first preset condition, which may specifically include at least one of the following: the first FPGA firmware fails integrity verification, and the version of the first FPGA firmware is not newer than the version of the original FPGA firmware (the version of the original FPGA firmware is the same as the version of the first FPGA firmware, or the version of the original FPGA firmware is newer than the version of the first FPGA firmware).

[0151] In one possible implementation, the version of the first FPGA firmware is newer than the version of the original FPGA firmware. Specifically, this may include having a version number that is higher than the version number of the original FPGA firmware. Here, the original FPGA firmware refers to the FPGA firmware used by the electronic device prior to the upgrade based on the first FPGA firmware.

[0152] As described above, in some embodiments of this application, the electronic device determines whether the first FPGA firmware meets the first preset condition. Specifically, this may include: the electronic device can verify the integrity of the first FPGA firmware and compare the version of the first FPGA firmware with the version of the original FPGA firmware. It is understood that this application does not restrict the order in which the electronic device performs the above two steps (verifying integrity and comparing versions). In one possible implementation, after receiving the first FPGA firmware sent by the OTA server, the electronic device can first verify the integrity of the first FPGA firmware. If the first FPGA firmware fails the integrity verification, it indicates that the first FPGA firmware does not meet the first preset condition, and the electronic device will not perform an FPGA firmware upgrade. If the first FPGA firmware passes the integrity verification, the electronic device can further compare the version of the first FPGA firmware with the version of the original FPGA firmware. If the version of the first FPGA firmware is not newer than the version of the original FPGA firmware, it indicates that the first FPGA firmware does not meet the first preset condition, and the electronic device will not perform an FPGA firmware upgrade. If the version of the first FPGA firmware is newer than the version of the original FPGA firmware, it indicates that the first FPGA firmware meets the first preset condition, and the electronic device can perform an FPGA firmware upgrade based on the first FPGA firmware.

[0153] In some embodiments of this application, the state machine may include three states: idle state, running state, and upgrade state. The state machine's state is related to the FPGA's operating mode; however, the state machine's state is a software state, while the FPGA's operating mode is a hardware operating mode, involving changes to the FPGA device hardware. The FPGA's operating mode may include two types: firmware upgrade mode and runtime mode. When the FPGA's operating mode is firmware upgrade mode, the FPGA can perform firmware upgrades through the upgrade interface provided by the electronic device. When the FPGA's operating mode is runtime mode, the electronic device can provide a control interface but not an upgrade interface. In this case, the FPGA cannot perform firmware upgrades through the upgrade interface, but the electronic device can configure the FPGA through the control interface. When the state machine is in the idle state, the FPGA is in runtime mode, no firmware upgrade is performed, and the electronic device is not configuring the FPGA through the control interface provided in runtime mode. When the state machine is in the running state, the FPGA is in runtime mode, no firmware upgrade is performed, but the electronic device is configuring the FPGA through the control interface provided in runtime mode. When the state machine is in the upgrade state, the FPGA is in firmware upgrade mode.

[0154] In one possible implementation, the processor in the electronic device can control the FPGA to perform firmware upgrades based on an upgrade interface. Similarly, the processor in the electronic device can configure the FPGA based on a control interface.

[0155] In some embodiments of this application, the upgrade interface mentioned in this application can be a JTAG interface simulated by the processor of an electronic device through multiple GPIO pins (such as the M GPIO pins mentioned above).

[0156] It is understood that the control interface mentioned in this application may be a serial peripheral interface (SPI) composed of multiple GPIO pins (such as the N GPIO pins mentioned above), or an inter-integrated circuit (I2C) interface or other communication interface, and this application does not limit it.

[0157] In some embodiments of this application, the pins of the upgrade interface and the control interface can be reused. For example, when the FPGA is in upgrade mode, the upgrade interface can be implemented using the M GPIO pins mentioned above, and when the FPGA is in runtime mode, the control interface can also be implemented using the M GPIO pins, or based on a portion of the M GPIO pins. That is, the M GPIO pins mentioned above and the N GPIO pins mentioned above can be completely different, partially the same, or completely the same.

[0158] In some embodiments of this application, when the state machine is in an idle state, the electronic device can switch the state of the state machine to the upgrade state; when the state machine is in other states, the electronic device does not need to perform this switch. That is, when the first FPGA firmware meets the first preset condition, if the state machine is in an idle state, the electronic device can switch the state of the state machine to the upgrade state; if the state machine is in a running state, the electronic device will not switch the state of the state machine to the upgrade state temporarily, but will wait until the state machine is in an idle state before switching the state machine to the upgrade state; if the state machine is in the upgrade state, the electronic device does not need to switch the state of the state machine to the upgrade state.

[0159] As can be understood, as mentioned above, the electronic device provides lock protection for the process of switching the state machine to the upgrade state. Specifically, this can include: the electronic device can protect itself from being affected by other state switching instructions when switching the state machine to the upgrade state. That is, if the electronic device receives an instruction to switch the state machine to another state (a state other than the upgrade state) or other instructions that affect the switch to the upgrade state during the process of switching the state machine to the upgrade state, the electronic device will not respond to the instruction and will continue to switch the state machine to the upgrade state.

[0160] In some embodiments of this application, the electronic device switches the state of the state machine to an upgraded state, and the switching process is protected by a lock. Specifically, this may include: the electronic device acquiring a state machine lock, switching the state of the state machine to the upgraded state, and then releasing the state machine lock. It should be noted that if the electronic device can acquire the state machine lock, it can switch the state of the state machine to the upgraded state. If the electronic device cannot acquire the state machine lock, it indicates that the electronic device is switching the state of the state machine (e.g., switching the state of the state machine from a running state to an idle state). This switching process is also protected by a lock, so the electronic device does not respond to other commands to switch the state of the state machine. In this case, the electronic device can wait until the state machine lock is released before acquiring it again.

[0161] As described above, in some embodiments of this application, if the electronic device can acquire the state machine lock and the state machine is in an idle state when the first FPGA firmware meets the first preset condition, the electronic device can switch the state machine to the upgrade state.

[0162] In some embodiments of this application, after the electronic device switches the state of the state machine to the upgrade state and releases the state machine lock, it can switch the FPGA's operating mode to the firmware upgrade mode.

[0163] S103: Erase the original FPGA firmware, program the first FPGA firmware into the FPGA, and apply the first FPGA firmware. During the process of erasing the original FPGA firmware, programming, and applying the first FPGA firmware, if it is necessary to set the GPIO level, write the preset value of the GPIO register corresponding to the target level into the first GPIO register. The first GPIO register is the register corresponding to the GPIO pin used to simulate JTAG.

[0164] After the electronic device switches the state machine to the upgrade state, it can erase the original FPGA firmware. After erasure, the first FPGA firmware is burned into the FPGA. After burning, the first FPGA firmware in the FPGA is applied (or the FPGA firmware is reconfigured as the first FPGA firmware).

[0165] In some embodiments of this application, after the electronic device switches the state machine to the upgrade state and releases the state machine lock, it can erase the original FPGA firmware and perform subsequent programming and reconfiguration operations.

[0166] In some embodiments of this application, the electronic device erasing the original FPGA firmware may specifically include: the electronic device erasing data related to the original FPGA firmware in the SRAM, and erasing data related to the original FPGA firmware in the FPGA's FLASH.

[0167] In some embodiments of this application, the electronic device programs the first FPGA firmware into the FPGA, specifically including: the electronic device programs the first FPGA firmware into the FPGA's FLASH.

[0168] It's understandable that setting GPIO levels in electronic devices means controlling the level of GPIO pins used to simulate JTAG, switching them from their original level to a target level, such as from high to low or vice versa. The original level of the GPIO pin can be high, and the target level can be low; conversely, the original level can also be low, and the target level can also be high.

[0169] Understandably, during the process of erasing the original FPGA firmware, programming, and applying the first FPGA firmware, the electronic device can control the high and low levels of the GPIO pins used to simulate JTAG to simulate corresponding JTAG commands (e.g., JTAG write commands to indicate erasing SRAM, JTAG write commands to indicate erasing FLASH, etc.). Furthermore, if simulating JTAG commands requires the electronic device to set (or switch) the level of the GPIO pins used to simulate JTAG, and the target level is high, the electronic device can write the preset value of the GPIO register corresponding to the high level into the first GPIO register. Conversely, if simulating JTAG commands requires the electronic device to set the level of the GPIO pins used to simulate JTAG, and the target level is low, the electronic device can write the preset value of the GPIO register corresponding to the low level into the first GPIO register.

[0170] In some embodiments of this application, the first GPIO register may include multiple fields, each field may include one or more bits, one of which may control the level of the corresponding GPIO pin (i.e., the GPIO pin used to simulate JTAG), while other fields may control other content, which is not limited in this application.

[0171] In some embodiments of this application, the preset value of the GPIO register corresponding to the target level may include the values ​​of multiple fields in the first GPIO register, and not just the value of the field in the first GPIO register used to control the corresponding GPIO level. In this case, when the target level changes, the value of the field in the first GPIO register used to control the corresponding GPIO pin level, included in the preset value of the GPIO register corresponding to the target level, changes, while the values ​​of other fields remain unchanged.

[0172] In some embodiments of this application, the electronic device has multiple GPIO pins for simulating JTAG, with each GPIO pin corresponding to a register (i.e., the GPIO register mentioned above). For example, the electronic device can simulate a 4-wire JTAG protocol. In this case, the electronic device can simulate the JTAG protocol through 4 GPIO pins, meaning there are 4 GPIO pins in the electronic device used for simulating JTAG. As another example, the electronic device can simulate a 7-wire JTAG protocol. In this case, the electronic device can simulate the JTAG protocol through 7 GPIO pins, meaning there are 7 GPIO pins in the electronic device used for simulating JTAG.

[0173] In the above situation, when it is necessary to set the level of a certain GPIO pin during the process of erasing the original FPGA firmware and burning the first FPGA firmware, the electronic device can write the preset value of the GPIO register corresponding to the target level into the GPIO register corresponding to that GPIO pin.

[0174] In some embodiments of this application, after the electronic device applies the first FPGA firmware in the FPGA, it can read the application status of the first FPGA firmware. If the application of the first FPGA firmware is successful, it indicates that the electronic device has completed the FPGA firmware upgrade. In this case, the electronic device can switch the state machine from the upgrade state to the idle state, and the switching process is protected by a lock.

[0175] Similar to the above, in some embodiments of this application, the electronic device switches the state of the state machine from the upgraded state to the idle state, and the switching process is protected by a lock. Specifically, the electronic device can acquire a state machine lock, switch the state of the state machine from the upgraded state to the idle state, and then release the state machine lock.

[0176] The following is combined with Figure 5 and Figure 6 The software and hardware structure of the electronic device shown is illustrated, and an FPGA firmware upgrade method provided in this application embodiment is introduced from the perspective of software and hardware interaction.

[0177] like Figure 8 As shown, to address needs such as bug fixing and feature introduction, the cloud-side OTA server can send the first FPGA firmware to the device on the edge. Correspondingly, the OTA engine in the user space of the electronic device can receive the first FPGA firmware sent by the OTA server. On one hand, the OTA engine can send the first FPGA firmware to the memory (e.g., ...). Figure 5 On the one hand, the internal memory shown is used for storage. On the other hand, if the user confirms the upgrade, the OTA engine can launch the FPGA firmware management service in user space to attempt an FPGA firmware upgrade. The FPGA firmware management service can verify the integrity of the first FPGA firmware and compare the version of the original FPGA firmware with the version of the first FPGA firmware. If the first FPGA firmware passes the integrity verification and its version is newer than the original FPGA firmware, the FPGA firmware management service can retrieve the first FPGA firmware from storage and write it to the corresponding device node in kernel space (e.g., / dev / fpga_update), triggering the FPGA firmware upgrade service in kernel space to initiate an FPGA firmware upgrade.

[0178] Furthermore, such as Figure 8As shown, after the FPGA firmware management service triggers the FPGA firmware upgrade service to initiate an FPGA firmware upgrade, on the one hand, the FPGA firmware upgrade service can instruct the state machine to switch its state to the upgrade state; on the other hand, the FPGA firmware upgrade service can call the protocol interface that matches the FPGA in the electronic device to implement the FPGA firmware upgrade. After the FPGA firmware upgrade service calls the corresponding protocol interface, it can trigger the JTAG emulation module in the kernel space to simulate the corresponding JTAG operations, such as the JTAG write instructions involved in erasing the original FPGA firmware, the JTAG write instructions and JTAG write data involved in burning the first FPGA firmware, the JTAG write instructions involved in firmware reconfiguration, and the JTAG write instructions and JTAG read data involved in reading the firmware application state. The JTAG emulation module's simulation of the corresponding JTAG operations involves setting (or switching) GPIO levels. In this case, the JTAG emulation module can trigger the acceleration module in the kernel space to set the GPIO levels. The acceleration module can determine the preset value of the GPIO register corresponding to the target level and write it into the first GPIO register, thereby controlling the GPIO level used for emulating JTAG to switch to the target level. It is understandable that electronic devices can control the FPGA by changing the value of the first GPIO register, such as erasing the original FPGA firmware stored in the FPGA's FLASH, burning the first FPGA firmware into the FPGA's FLASH, and triggering the FPGA to apply the first FPGA firmware, as mentioned above.

[0179] The following describes a specific implementation of the above embodiments.

[0180] Please see Figures 9A-9C , Figures 9A-9C A flowchart illustrating a set of FPGA firmware upgrade methods provided in this application embodiment. The method may include, but is not limited to, the following steps:

[0181] 1. When an FPGA firmware upgrade is triggered, the state machine is switched to the upgrade state, and the process is protected by a lock (e.g., Figure 9A (As shown).

[0182] S201: The initialization module performs initialization processing and creates an FPGA firmware upgrade service.

[0183] In response to an operation that starts the electronic device (e.g., pressing and holding the power button), the electronic device can begin to boot up. During this process, the initialization module in the user space of the electronic device can perform initialization processing and create an FPGA firmware upgrade service.

[0184] In some embodiments of this application, the initialization module performs initialization processing, which may specifically include: (1) acquiring the GPIO pins used to simulate JTAG and initializing them; (2) acquiring the FPGA clock and power supply and initializing them, that is, setting the FPGA clock according to the FPGA's standard operating frequency and setting the FPGA power supply according to the FPGA's rated operating voltage; (3) acquiring the GPIO pins used to control the FPGA's operating mode and initializing them; (4) initializing the state machine, setting its state to the idle state, and initializing the state machine lock, that is, setting it to the state of not acquiring the lock.

[0185] It is understandable that initializing GPIO pins can specifically include: configuring GPIO pins used for controlling level switching as output mode GPIO pins, and configuring GPIO pins used for reading device status as input mode GPIO pins.

[0186] In some embodiments of this application, the initialization module can call the ioremap function to convert the base address of the register corresponding to the acquired GPIO pin into a virtual address that the CPU can recognize, facilitating subsequent operations. Specifically, the ioremap function can be used to map an I / O address space to the kernel's virtual address space for easier access.

[0187] S202: The OTA server sends the first FPGA firmware to the OTA engine.

[0188] As mentioned above, to address the needs of fixing high-risk security vulnerabilities related to FPGAs, fixing FPGA-related issues affecting system stability, and introducing performance improvements and new features, OEMs can use OTA servers to send new FPGA firmware to the device side. For example, an OTA server can send the first FPGA firmware to an electronic device, and the OTA engine in the electronic device can receive the first FPGA firmware sent by the OTA server.

[0189] S203: If the user confirms the upgrade, the OTA engine will launch the FPGA firmware management service to attempt the FPGA firmware upgrade.

[0190] After receiving the first FPGA firmware sent by the OTA server, the OTA engine can prompt the user to confirm whether to perform an FPGA firmware upgrade. For example, the OTA engine can trigger a prompt box on the electronic device or use voice prompts to confirm whether an FPGA firmware upgrade is needed. If the user confirms the upgrade, the OTA engine can launch the FPGA firmware management service in the electronic device's user space to attempt the FPGA firmware upgrade.

[0191] In some embodiments of this application, when fpga_trigger_update is set to true in the FPGA firmware management service rc file, the FPGA firmware management service initiates an FPGA firmware upgrade. Here, fpga_trigger_update is an Android attribute.

[0192] Based on the above, in some embodiments of this application, when the user confirms the upgrade, the OTA engine can set fpga_trigger_update to true, thereby launching the FPGA firmware management service to upgrade the FPGA firmware.

[0193] S204: The FPGA firmware management service verifies the integrity of the first FPGA firmware and compares the version of the first FPGA firmware with the version of the original FPGA firmware.

[0194] After the OTA engine initiates the FPGA firmware management service, the FPGA firmware management service can verify the integrity of the first FPGA firmware, such as checking whether the first FPGA firmware has missing data, and can also compare the version of the first FPGA firmware with the version of the original FPGA firmware. As described above, in some embodiments of this application, the FPGA firmware management service compares the version of the first FPGA firmware with the version of the original FPGA firmware, specifically including: the FPGA firmware management service compares whether the version number of the first FPGA firmware is higher than the version number of the original FPGA firmware.

[0195] It is understood that this application does not limit the order in which the FPGA firmware management service verifies the integrity of the first FPGA firmware and compares the version of the first FPGA firmware with the version of the original FPGA firmware. As mentioned above, in some embodiments of this application, the FPGA firmware management service may first verify the integrity of the first FPGA firmware, and if the first FPGA firmware passes the integrity verification, the FPGA firmware management service then compares the version of the first FPGA firmware with the version of the original FPGA firmware.

[0196] S205: If the first FPGA firmware passes the integrity verification and the version of the first FPGA firmware is newer than the version of the original FPGA firmware, the FPGA firmware management service triggers the FPGA firmware upgrade service to upgrade the FPGA firmware.

[0197] In some embodiments of this application, if the version number of the first FPGA firmware is higher than the version number of the original FPGA firmware, it means that the version of the first FPGA firmware is newer than the version of the original FPGA firmware.

[0198] In some embodiments of this application, if the first FPGA firmware passes integrity verification and the version of the first FPGA firmware is newer than the version of the original FPGA firmware, the FPGA firmware management service can write the first FPGA firmware into the device node provided by the FPGA driver in the kernel space of the electronic device (e.g., / dev / fpga_update), thereby triggering the FPGA firmware upgrade service in the kernel space of the electronic device to perform FPGA firmware upgrade.

[0199] S206: FPGA firmware upgrade service indicates that the state machine has switched to the upgrade state.

[0200] After the FPGA firmware management service triggers the FPGA firmware upgrade service to perform an FPGA firmware upgrade, the FPGA firmware upgrade service can instruct the state machine in the kernel space of the electronic device to switch to the upgrade state.

[0201] As mentioned above, in some embodiments of this application, the state machine can only switch to the upgrade state when it is in the idle state, while it cannot switch to the upgrade state when it is in the running state. It can only switch to the upgrade state when it switches from the running state to the idle state.

[0202] As you can understand, the relevant descriptions of the three states of a state machine can be found above, and will not be repeated here.

[0203] S207: The state machine acquires the state machine lock.

[0204] In response to the FPGA firmware upgrade service instructing the state machine to switch to the upgrade state, the state machine can acquire a state machine lock. If the state machine lock can be acquired, the state machine can continue to execute steps S208 and S209. If the state machine lock cannot be acquired, the state machine cannot switch to the upgrade state and must wait until the state machine lock is acquired before it can switch to the upgrade state.

[0205] S208: The state machine switches to the upgrade state.

[0206] After acquiring the state machine lock, the state machine can switch its state to the upgrade state.

[0207] S209: The state machine releases the state machine lock.

[0208] After the state machine switches to the upgrade state, the state machine lock can be released.

[0209] S210: The FPGA firmware upgrade service triggers the switch of the FPGA's operating mode to firmware upgrade mode.

[0210] After switching the state machine to the upgrade state and releasing the state machine lock, the FPGA firmware upgrade service can trigger a switch to the firmware upgrade mode for the FPGA. Specifically, the FPGA firmware upgrade service can trigger the setting of the GPIO pin levels used to control the FPGA's operating mode, thus switching the FPGA's operating mode to firmware upgrade mode. It can be understood that different GPIO pin levels corresponding to different FPGA operating modes correspond to different FPGA operating modes. When the upper layer issues a command to switch the FPGA operating mode, the electronic device can adjust the levels of the GPIO pins according to the above correspondence, thereby achieving the switching of the FPGA operating mode.

[0211] 2. After the state machine switches to the upgrade state, erase the original FPGA firmware and program the first FPGA firmware (e.g., ...). Figure 9B (As shown).

[0212] S211: The FPGA firmware upgrade service calls the FPGA vendor's firmware upgrade protocol module to erase the original FPGA firmware.

[0213] After the state machine switches to the upgrade state, the FPGA firmware upgrade service can call the interface of the corresponding FPGA vendor's firmware upgrade protocol (i.e., the interface of the firmware upgrade protocol provided by the vendor corresponding to the FPGA currently used by the electronic device) to erase the original FPGA firmware. It can be understood that the original FPGA firmware refers to the FPGA firmware used by the electronic device before the upgrade based on the first FPGA firmware; its relevant description can be found above, and will not be repeated here.

[0214] It is understandable that the specific implementation of the FPGA firmware upgrade service calling the FPGA vendor's firmware upgrade protocol module to erase the original FPGA firmware may include steps S213-S219.

[0215] S212: The FPGA vendor firmware upgrade protocol module disables interrupts.

[0216] After the FPGA firmware upgrade service invokes the corresponding FPGA vendor firmware upgrade protocol module (i.e., a module encapsulating a protocol compatible with the FPGA device currently used in the electronic device), this FPGA vendor firmware upgrade protocol module can disable processor (e.g., CPU) interrupts to protect the atomic operations specified by the corresponding FPGA vendor firmware upgrade protocol. It can be understood that an atomic operation refers to an operation that cannot be interrupted.

[0217] In some embodiments of this application, the atomic operations specified in the corresponding FPGA firmware upgrade protocol may include erasing the original FPGA firmware. In this case, when the FPGA firmware upgrade service calls the interface of the corresponding FPGA vendor's firmware upgrade protocol to perform the operation of erasing the original FPGA firmware, interrupt disabling can be triggered to protect the operation of erasing the original FPGA firmware.

[0218] As you can understand, disabling interrupts means turning off system interrupts, preventing the system from interrupting continuous operation. The purpose of disabling interrupts is to protect currently executing programs from being interrupted, especially when handling urgent or important tasks. For example, in a multiprogramming environment, the CPU uses interrupts to switch between programs. When an emergency occurs, the CPU needs to pause the current task to handle the emergency; in this case, interrupts need to be disabled to ensure that the original task can continue execution only after the event is handled.

[0219] S213: The FPGA vendor firmware upgrade protocol module triggers the JTAG emulation module to erase data in SRAM related to the original FPGA firmware.

[0220] After the interrupt is disabled, the corresponding FPGA vendor firmware upgrade protocol module can trigger the JTAG emulation module to erase the data related to the original FPGA firmware in the SRAM. The JTAG emulation module erases the data related to the original FPGA firmware in the SRAM by controlling the corresponding GPIO pins to simulate the JTAG protocol and write instructions to the FPGA, which can be specifically achieved through steps S214 and S215.

[0221] S214: The JTAG emulation module simulates JTAG write commands. During the simulation of JTAG write commands, the acceleration module is triggered to set the GPIO level.

[0222] The JTAG emulation module can erase data related to the original FPGA firmware in SRAM by emulating JTAG write commands. As we understand it, JTAG write commands involve multiple operations to set the GPIO pin levels (simply put, setting GPIO levels). This means that during the JTAG emulation module's simulation of JTAG write commands, the JTAG emulation module can trigger the acceleration module to set the levels of the corresponding GPIO pins.

[0223] As is understandable, the JTAG emulation module simulates JTAG write commands, and correspondingly, the FPGA in the electronic device can receive these commands. After receiving the commands, the FPGA can erase the data in the SRAM related to the original FPGA firmware.

[0224] It's important to note that before the JTAG emulation module controls the corresponding GPIO pins to simulate JTAG write commands, write data, or read data, the JTAG state must match the simulation state; this is defined by the JTAG protocol. For example, when the JTAG state is Shift+IR, the JTAG emulation module can simulate a JTAG write command. This state indicates a transfer command, shifting the data from TDI into the instruction register on each rising edge of TCK. As another example, when the JTAG state is Shift+DR, the JTAG emulation module can simulate a JTAG write or read data. This state indicates a data transfer, shifting the data from TDI into a shift register on each rising edge of TCK, and shifting the bit closest to TDO to the TDO pin. Finally, after the simulation ends, the JTAG state needs to return to Exit1+IR, indicating the end of instruction transfer and preparation for updating the instruction register.

[0225] This application uses a 4-line JTAG as an example, combined with Figures 10A-10E This paper introduces the specific implementation methods for JTAG state switching and simulating write commands, write data, read data, or run tests. It can be understood that a 4-wire JTAG refers to a JTAG interface composed of four signal lines: a test clock signal, a test mode select signal, a test data input signal, and a test data output signal. The test clock signal (TCK) is used to synchronize data transmission, the test mode select signal (TMS) is used to control the JTAG state machine, the test data input signal (TDI) is used to send test data to the chip, and the test data output signal (TDO) is used to read test data from the chip. In this application, four corresponding GPIO pins in an electronic device are used to simulate these four signal lines, thereby implementing the simulated JTAG protocol. For ease of understanding and description, these four GPIO pins used to simulate JTAG are referred to as the TCK pin, TMS pin, TDI pin, and TDO pin.

[0226] The following is a combination of... Figure 10A This paper introduces a specific implementation method for JTAG state switching.

[0227] Please see Figure 10A , Figure 10A A flowchart illustrating a JTAG state switching method provided in this application embodiment. This method may include, but is not limited to, the following steps:

[0228] S301: The JTAG simulation module determines the target level of the TMS pin according to the switching of the JTAG state.

[0229] The JTAG emulation module can determine the JTAG state to be switched based on the operation to be simulated next, i.e. the target JTAG state, and pull the GPIO simulated TMS high or low based on the target JTAG state, or determine the target level of the TMS pin based on the target JTAG state, that is, determine the level of the TMS pin corresponding to the target JTAG state as the target level of the TMS pin.

[0230] In some embodiments of this application, the signal line levels corresponding to different JTAG states are different, and correspondingly, the levels of the GPIO pins used to simulate JTAG are different. That is, there is a correspondence between the JTAG state, the signal line level, and the level of the GPIO pin used to simulate JTAG. For example, if the TMS level corresponding to a certain JTAG state is high, the target level of its corresponding TMS pin is high; while if the TMS level corresponding to another JTAG state is low, the target level of its corresponding TMS pin is low.

[0231] For example, if the JTAG emulation module needs to emulate a JTAG write command next, it first needs to switch the JTAG state to Shift+IR. The JTAG emulation module can determine the TMS level required to switch to Shift+IR according to the JTAG protocol, that is, obtain the target level of the TMS pin.

[0232] S302: The JTAG analog module sends information to the acceleration module to indicate the target level of the TMS pin.

[0233] After the JTAG simulation module determines the target level of the TMS pin, it can send information indicating the target level of the TMS pin to the acceleration module. Correspondingly, the acceleration module can receive the information indicating the target level of the TMS pin sent by the JTAG simulation module.

[0234] S303: The acceleration module writes the preset value of the GPIO register corresponding to the target level of the TMS pin into the GPIO register corresponding to the TMS pin.

[0235] After receiving the information sent by the JTAG simulation module to indicate the target level of the TMS pin, the acceleration module can determine the preset value of the GPIO register corresponding to the target level of the TMS pin and write it into the GPIO register corresponding to the TMS pin.

[0236] For example, if the target level of the TMS pin is high, the acceleration module can write the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TMS pin.

[0237] The following describes the specific implementation method of writing the preset value of the GPIO register corresponding to the target level of the TMS pin into the GPIO register corresponding to the TMS pin.

[0238] After determining the preset value of the GPIO register corresponding to the target level of the TMS pin, the acceleration module can obtain the gpio_chip instance based on the gpiod_to_chip function and the gpio_desc instance obtained during resource allocation. Furthermore, it can obtain the register offset address corresponding to the TMS pin, i.e., the GPIO configuration register offset address corresponding to the TMS, based on the desc_to_gpio function and the gpio_chip instance. During initialization, the acceleration module can obtain the register base address corresponding to the GPIO pin used for simulating JTAG, i.e., the GPIO configuration register base address operable by the CPU. Further, the acceleration module can obtain the GPIO configuration register address based on this register base address and the register offset address, and then write the preset value into the register corresponding to this GPIO configuration register address.

[0239] As is understandable, the desc_to_gpio function is a native Linux kernel interface used to convert abstract GPIO descriptors into integers that are easy for the kernel to manipulate and index.

[0240] In some embodiments of this application, the base addresses of the GPIO registers corresponding to multiple GPIO pins used to simulate JTAG are the same, but the offset addresses are different. In this case, when the acceleration module writes the preset value of the GPIO register corresponding to the target level of a GPIO pin used to simulate JTAG into its corresponding GPIO register, it can obtain the base address of the GPIO register, and obtain the offset address of the GPIO register based on the number corresponding to the GPIO pin. Then, based on the base address and offset address of the GPIO register, it obtains the specific GPIO configuration register address, and then writes the preset value into the register corresponding to the specific GPIO configuration register address.

[0241] In one possible implementation, the acceleration module can obtain the corresponding register offset address based on the number corresponding to the TMS pin.

[0242] As you can understand, `gpiod_to_chip` is a function that returns the GPIO chip to which a GPIO descriptor belongs. The function's purpose is to obtain the GPIO chip to which a GPIO descriptor belongs. In the Linux kernel, GPIO device drivers are managed through GPIO chips, and each GPIO descriptor is associated with a specific GPIO chip. The `gpiod_to_chip` function finds the GPIO chip to which a GPIO descriptor belongs, allowing further manipulation of other GPIO pins on that chip.

[0243] In some embodiments of this application, the acceleration module can use the `_raw_write` function to write the preset value into the register corresponding to the GPIO configuration register address. The `_raw_write` function is primarily used to write data into hardware registers.

[0244] S304: The JTAG analog module determines that the target level of the TCK pin is low.

[0245] After setting the TMS pin level, the JTAG emulation module can pull the GPIO-emulated TCK low. In other words, by setting the TMS pin level, the JTAG emulation module can determine the target level of the TCK pin. At this point, the target level of the TCK pin is low.

[0246] S305: The JTAG analog module sends information to the acceleration module to indicate a low level.

[0247] After the JTAG simulation module determines that the target level of the TCK pin is low, it can send information indicating the low level to the acceleration module. Correspondingly, the acceleration module can receive the low-level information sent by the JTAG simulation module.

[0248] S306: The acceleration module writes the preset value of the GPIO register corresponding to the low level into the GPIO register corresponding to the TCK pin.

[0249] After receiving the information sent by the JTAG simulation module to indicate a low level, the acceleration module can determine that the preset value of the GPIO register corresponding to the target level of the TCK pin is the preset value of the GPIO register corresponding to the low level, and write it into the GPIO register corresponding to the TCK pin.

[0250] It is understandable that the specific implementation of writing the GPIO register corresponding to the TCK pin by the acceleration module can be found in step S303, and will not be elaborated here.

[0251] S307: The JTAG simulation module adds a delay based on the target operating frequency to the current duty cycle.

[0252] After the JTAG simulation module instructs the acceleration module to pull low (as shown in steps S305 and S306), a delay determined based on the target operating frequency can be added to the current working cycle, thereby making its actual operating frequency conform to the target operating frequency. It can be understood that the target operating frequency is the hardware-specified operating frequency for updating FPGA firmware via the JTAG interface, i.e., the operating frequency of the FPGA firmware upgrade simulated by the electronic device, such as the 2MHz mentioned above. In some embodiments of this application, the target operating frequency can be a specific value, such as the 2MHz mentioned above, or any value within a frequency range, such as any value between 2MHz and 2.5MHz mentioned above.

[0253] In some embodiments of this application, the delay determined based on the target operating frequency can be a pre-set delay, the specific data of which can be calculated backwards according to actual needs. For example, the delay can be 200 milliseconds.

[0254] In some embodiments of this application, the delay determined based on the target operating frequency can be the difference between the operating cycle without added delay (i.e., the reciprocal of the current operating frequency) and the operating cycle corresponding to the target operating frequency. This process is the reverse calculation process mentioned above.

[0255] S308: The JTAG simulation module determines that the target level of the TCK pin is high.

[0256] After setting the TMS pin level, the JTAG emulation module can pull the GPIO-emulated TCK high. In other words, the JTAG emulation module determines the delay based on the target operating frequency. Once the actual operating frequency reaches the target frequency, it can switch the TCK pin level according to the target operating frequency, i.e., switch the TCK pin level high based on the actual operating frequency obtained after adding the delay. At this point, the JTAG emulation module can determine that the target level of the TCK pin is high.

[0257] S309: The JTAG analog module sends a high-level indication to the acceleration module.

[0258] After the JTAG simulation module determines that the target level of the TCK pin is high, it can send information indicating the high level to the acceleration module. Correspondingly, the acceleration module can receive the high-level indication information sent by the JTAG simulation module.

[0259] S310: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TCK pin.

[0260] After receiving the information sent by the JTAG simulation module to indicate a high level, the acceleration module can determine the preset value of the GPIO register corresponding to the target level of the TCK pin as the preset value of the GPIO register corresponding to the high level, and write it into the GPIO register corresponding to the TCK pin.

[0261] It is understandable that the specific implementation of writing the GPIO register corresponding to the TCK pin by the acceleration module can be found in step S303, and will not be elaborated here.

[0262] In some embodiments of this application, after the acceleration module executes step S310, the JTAG simulation module can execute step S307 to control the duty cycle, thereby enabling the actual operating frequency to reach the target operating frequency. It is understood that the delay added after the JTAG simulation module instructs the acceleration module to pull down (as shown in steps S305 and S306) can be the same as the delay added after the JTAG simulation module instructs the acceleration module to pull up (as shown in steps S309 and S310) (e.g., the 200 milliseconds mentioned above), or it can be different (because the current duty cycle is different, the delay determined based on the target operating frequency will differ).

[0263] In some embodiments of this application, the JTAG emulation module adds only one delay within a JTAG work cycle. For example, if the JTAG emulation module instructs the acceleration module to pull low before executing step S307, then after the acceleration module executes step S310, the JTAG emulation module may not execute step S307 until the JTAG emulation module instructs the acceleration module to pull low again before executing step S307. As another example, if the JTAG emulation module instructs the acceleration module to pull high before executing step S307, then after the acceleration module executes step S306 again, the JTAG emulation module may not execute step S307 until the JTAG emulation module instructs the acceleration module to pull high again before executing step S307.

[0264] It is understandable that if the JTAG state switching is not completed after the acceleration module executes step S310, the JTAG simulation module and the acceleration module can execute steps S301-S310 again.

[0265] The following is combined with Figure 10B This paper introduces a specific implementation method for simulating write commands using a JTAG emulation module.

[0266] Please see Figure 10B , Figure 10B A flowchart illustrating a method for simulating JTAG write commands, provided in an embodiment of this application. This method may include, but is not limited to, the following steps:

[0267] S401: The JTAG emulation and acceleration modules switch the JTAG state to Shift+IR.

[0268] Before simulating JTAG write commands, the JTAG emulation module needs to switch the JTAG state to Shift+IR. During this switch, the acceleration module can be triggered to set the voltage levels of the corresponding GPIO pins, involving voltage changes on the GPIO pins used for simulating JTAG. For details on how to switch the JTAG state, please refer to [link / reference needed]. Figure 10A Steps S301-S310 shown are not repeated here.

[0269] As you can understand, Shift+IR represents a transfer instruction, which moves the TDI data into the instruction register on each rising edge of TCK.

[0270] S402: If the bit to be written in the instruction is the last bit of the instruction, the JTAG simulation module determines that the target level of the TMS pin is high.

[0271] During the simulated write instruction process, the JTAG simulation module can determine whether the bit to be written is the last bit of the instruction each time it writes 1 bit. If the bit to be written is the last bit of the instruction, the GPIO-simulated TMS pin can be pulled high. That is, when the JTAG simulation module writes the last bit of data, it can determine that the target level of the TMS pin is high and execute steps S403-S404. If the bit to be written is not the last bit of the instruction, the JTAG simulation module can execute step S405 and subsequent steps.

[0272] S403: The JTAG analog module sends a high-level indication to the acceleration module.

[0273] After the JTAG simulation module determines that the target level of the TMS pin is high, it can send information indicating the high level to the acceleration module. Correspondingly, the acceleration module can receive the high-level indication information sent by the JTAG simulation module.

[0274] S404: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TMS pin.

[0275] After receiving the information sent by the JTAG simulation module to indicate a high level, the acceleration module can determine the preset value of the GPIO register corresponding to the target level of the TMS pin as the preset value of the GPIO register corresponding to the high level, and write it into the GPIO register corresponding to the TMS pin.

[0276] It is understandable that the specific implementation of writing the GPIO register corresponding to the TMS pin by the acceleration module can be found in step S303, and will not be elaborated here.

[0277] S405: The JTAG simulation module determines the target level of the TDI pin according to the value of the current bit to be written in the instruction.

[0278] If the bit to be written in the instruction is the last bit of the instruction, after the JTAG simulation module can trigger the acceleration module to write the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TMS pin, the JTAG simulation module can determine the target level of the TDI pin according to the value of the bit to be written in the instruction.

[0279] If the bit to be written in the instruction is not the last bit of the instruction, the JTAG simulation module can directly determine the target level of the TDI pin according to the value of the bit to be written in the instruction.

[0280] If the bit to be written is 0, the JTAG simulation module can determine that the target level of the TDI pin is low. If the bit to be written is 1, the JTAG simulation module can determine that the target level of the TDI pin is high.

[0281] S406: The JTAG simulation module sends information to the acceleration module to indicate the target level of the TDI pin.

[0282] After the JTAG simulation module determines the target level of the TDI pin, it can send information indicating the target level of the TDI pin to the acceleration module. Correspondingly, the acceleration module can receive the information indicating the target level of the TDI pin sent by the JTAG simulation module.

[0283] S407: The acceleration module writes the preset value of the GPIO register corresponding to the target level of the TDI pin into the GPIO register corresponding to the TDI pin.

[0284] After receiving the information sent by the JTAG simulation module to indicate the target level of the TDI pin, the acceleration module can determine the preset value of the GPIO register corresponding to the target level of the TDI pin and write it into the GPIO register corresponding to the TDI pin.

[0285] It is understandable that the specific implementation of writing the GPIO register corresponding to the TDI pin by the acceleration module can be found in step S303, and will not be elaborated here.

[0286] S408: The JTAG analog module determines that the target level of the TCK pin is low.

[0287] The JTAG simulation module determines the target level of the TDI pin according to the high or low level of the bit to be written in the instruction, and triggers the acceleration module to write the preset value of the GPIO register corresponding to the target level of the TDI pin into the register corresponding to the TDI pin. After that, it can be determined that the target level of the TCK pin is low.

[0288] S409: The JTAG analog module sends a low-level indication to the acceleration module.

[0289] S410: The acceleration module writes the preset value of the GPIO register corresponding to the low level into the GPIO register corresponding to the TCK pin.

[0290] S411: The JTAG simulation module adds a delay based on the target operating frequency to the current duty cycle.

[0291] S412: The JTAG simulation module determines that the target level of the TCK pin is high.

[0292] S413: The JTAG analog module sends a high-level indication to the acceleration module.

[0293] S414: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TCK pin.

[0294] It is understandable that the specific implementation of steps S408-S414 can be referred to the relevant descriptions of steps S304-S310.

[0295] It is understandable that if the instruction writing is not completed after the acceleration module executes step S414, the JTAG simulation module and the acceleration module can execute steps S401-S414 again.

[0296] In some embodiments of this application, after the acceleration module executes step S414, the JTAG simulation module can execute step S411 to control the working cycle, so that the actual working frequency reaches the target working frequency.

[0297] S415: The JTAG emulation and acceleration modules switch the JTAG state to Exit+IR until it returns to IDLE.

[0298] After writing the instructions, the JTAG emulation module needs to switch the JTAG state to Exit+IR until it returns to IDLE. During this state switching process, the acceleration module can be triggered to set the level of the corresponding GPIO pins, which involves level changes of the GPIO pins used for emulating JTAG. For specific details on how to switch the JTAG state, please refer to [link / reference]. Figure 10A Steps S301-S310 shown are not repeated here.

[0299] As you can understand, Exit+IR indicates the end of instruction transfer, preparing for the instruction to update the instruction register. The IDLE state represents an idle state, in which no operation is performed, waiting for a command or event to trigger another state.

[0300] S215: The JTAG emulation module enters the JTAG runtime test state. During the process of entering the JTAG runtime test state, the acceleration module is triggered to set the GPIO level.

[0301] After the JTAG emulation module simulates JTAG write commands, it can enter the JTAG runtest state. Understandably, in the JTAG runtest state, the clock drives the FPGA device upgrade, and the electronic device does not require any other operation. This means that the acceleration module will also be triggered to set the GPIO level in this state.

[0302] The following is combined with Figure 10C This paper introduces a specific implementation method for simulating entering the JTAG runtime test state using a JTAG simulation module.

[0303] Please see Figure 10C , Figure 10C This application provides a flowchart for entering the JTAG runtime test state. The method may include, but is not limited to, the following steps:

[0304] S501: The JTAG analog module determines that the target level of the TCK pin is low.

[0305] S502: The JTAG analog module sends information to the acceleration module to indicate a low level.

[0306] S503: The acceleration module writes the preset value of the GPIO register corresponding to the low level into the GPIO register corresponding to the TCK pin.

[0307] S504: The JTAG simulation module adds a delay based on the target operating frequency to the current working cycle.

[0308] S505: The JTAG analog module determines that the target level of the TCK pin is high.

[0309] S506: The JTAG analog module sends a high-level indication to the acceleration module.

[0310] S507: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TCK pin.

[0311] As can be understood, as mentioned above, the running test state refers to a state where only the clock is present and no other operations are performed, i.e., only changes in the TCK pin level are involved. The specific implementation methods of steps S501-S507 can be found in the relevant descriptions of steps S304-S310.

[0312] In some embodiments of this application, after the acceleration module executes step S507, the JTAG simulation module can execute step S504 to control the working cycle, so that the actual working frequency reaches the target working frequency.

[0313] It is understandable that if the acceleration module executes step S507 but the test clock cycles have not yet been completed, the JTAG simulation module and the acceleration module can execute steps S501-S507 again.

[0314] S216: The FPGA firmware upgrade service calls the FPGA vendor's firmware upgrade protocol module to trigger the JTAG emulation module to erase data related to the original FPGA firmware in the FLASH memory.

[0315] After the FPGA firmware upgrade service calls the FPGA vendor's firmware upgrade protocol module to erase the data related to the original FPGA firmware in the SRAM, it can continue to call the FPGA vendor's firmware upgrade protocol module to trigger the JTAG emulation module to erase the data related to the original FPGA firmware in the FLASH. The JTAG emulation module erases the data related to the original FPGA firmware in the FLASH by controlling the corresponding GPIO pins to simulate the JTAG protocol and write instructions to the FPGA, which can be specifically achieved through steps S217 and S218.

[0316] S217: The JTAG emulation module simulates JTAG write commands. During the simulation of JTAG write commands, the acceleration module is triggered to set the GPIO level.

[0317] Similar to the above-described method for erasing data related to the original FPGA firmware in SRAM, the JTAG simulation module can erase data related to the original FPGA firmware in FLASH by simulating JTAG write commands. It is understood that the relevant description of the JTAG write commands can be found in step S214, and will not be repeated here.

[0318] As is understandable, the JTAG emulation module simulates JTAG write commands, and correspondingly, the FPGA in the electronic device can receive these commands. After receiving the commands, the FPGA can erase the data in the FLASH memory associated with the original FPGA firmware.

[0319] It should be noted that the level switching of the GPIO pins corresponding to the JTAG write instructions involved in steps S214 and S217 may be different, and this application does not impose any restrictions on this.

[0320] S218: The JTAG emulation module enters the JTAG runtime test state. During the process of entering the JTAG runtime test state, the acceleration module is triggered to set the GPIO level.

[0321] After the JTAG emulation module simulates JTAG write commands, it can enter the JTAG runtime test state. A description of the JTAG runtime test state can be found in step S215, and will not be repeated here.

[0322] S219: The FPGA firmware upgrade service calls the FPGA vendor firmware upgrade protocol module to enable interrupts.

[0323] After the FPGA firmware upgrade service calls the interface of the corresponding FPGA vendor's firmware upgrade protocol to erase the data related to the original FPGA firmware in SRAM and FLASH, it can enable the interrupt of the processor (e.g., CPU).

[0324] As you can understand, enabling interrupts means that the system can be interrupted during continuous operation to run interrupt service functions. Enabling interrupts is to resume normal program execution and allow the CPU to respond to other interrupt requests.

[0325] S220: The FPGA firmware upgrade service calls the FPGA vendor's firmware upgrade protocol module to burn the first FPGA firmware.

[0326] After erasing the original FPGA firmware, the FPGA firmware upgrade service can call the corresponding FPGA vendor firmware upgrade protocol module to burn the first FPGA firmware transmitted to the kernel space into the FPGA device's FLASH.

[0327] It is understandable that the specific implementation of the FPGA firmware upgrade service calling the FPGA vendor's firmware upgrade protocol module to burn the first FPGA firmware may include steps S221-S226.

[0328] It should be noted that the electronic device can program the first FPGA firmware in the smallest unit, or in other words, program the first FPGA firmware according to the smallest granularity. That is, the FPGA firmware upgrade service can call the FPGA vendor's firmware upgrade protocol module to program the first FPGA firmware, and each time it programs the data of the smallest unit. It can be understood that the electronic device can repeatedly execute the step of programming the smallest unit data in the first FPGA firmware. The specific steps for programming the smallest unit data in the first FPGA firmware can be found in steps S221-S226. In this case, the FPGA firmware upgrade service can call the FPGA vendor's firmware upgrade protocol module to repeatedly execute steps S221-S226.

[0329] In some embodiments of this application, the smallest unit data in the first FPGA firmware can be 256 bytes of data.

[0330] It is understandable that the smallest unit of data in the first FPGA firmware can be the atomic operation mentioned above.

[0331] S221: The FPGA vendor firmware upgrade protocol module disables interrupts.

[0332] After the FPGA firmware upgrade service calls the corresponding FPGA vendor firmware upgrade protocol module, the FPGA vendor firmware upgrade protocol module can disable processor (e.g., CPU) interrupts to protect the atomic operations specified by the corresponding FPGA vendor firmware upgrade protocol, such as burning the smallest unit data in the first FPGA firmware.

[0333] It is understood that the relevant description of disabling interrupts can be found in step S212, and will not be repeated here.

[0334] S222: The FPGA vendor firmware upgrade protocol module triggers the JTAG simulation module to write the smallest unit data in the first FPGA firmware into the FPGA's FLASH.

[0335] After interrupts are disabled, the FPGA vendor firmware upgrade protocol module can trigger the JTAG emulation module to write the smallest unit data in the first FPGA firmware into the FPGA's FLASH. The JTAG emulation module can write the smallest unit data in the first FPGA firmware into the FPGA's FLASH by controlling the corresponding GPIO pins to simulate the JTAG protocol and write instructions and data to the FPGA, which can be achieved through steps S223-S225.

[0336] S223: The JTAG emulation module simulates JTAG write commands. During the simulation of JTAG write commands, the acceleration module is triggered to set the GPIO level.

[0337] The JTAG emulation module writes the smallest unit of data in the first FPGA firmware to the FPGA's FLASH, initially emulating JTAG write commands. As mentioned above, JTAG write commands can involve multiple GPIO level settings, meaning that during the JTAG emulation module's simulation of JTAG write commands, the JTAG emulation module can trigger the acceleration module to set the levels of the corresponding GPIO pins.

[0338] Understandably, the relevant descriptions of JTAG write commands can be found in step S214 and as follows. Figure 10B Steps S401-S415 shown are not repeated here.

[0339] S224: The JTAG emulation module simulates JTAG data writing. During the simulated JTAG data writing process, the acceleration module is triggered to set the GPIO level.

[0340] After the JTAG emulation module emulates the JTAG write command, it can simulate JTAG data writing, thereby writing the smallest unit of data in the first FPGA firmware to the FPGA's FLASH.

[0341] Similar to JTAG write commands, JTAG data writing can also involve multiple operations to set GPIO levels. This means that during the process of the JTAG emulation module simulating JTAG data writing, the JTAG emulation module can trigger the acceleration module to set the level of the corresponding GPIO pin.

[0342] The following is combined with Figure 10D This paper introduces a specific implementation method for simulating data writing using a JTAG simulation module.

[0343] Please see Figure 10D , Figure 10D A flowchart illustrating a method for simulating JTAG data writing, provided as an embodiment of this application. This method may include, but is not limited to, the following steps:

[0344] S601: The JTAG emulation and acceleration modules switch the JTAG state to Shift+DR.

[0345] Before the JTAG emulation module can emulate JTAG write data, it needs to switch the JTAG state to Shift+DR. During this switch, the acceleration module can be triggered to set the voltage levels of the corresponding GPIO pins, thus involving voltage changes on the GPIO pins used for emulating JTAG. For details on how to switch the JTAG state, please refer to [link / reference needed]. Figure 10A Steps S301-S310 shown are not repeated here.

[0346] As you can understand, Shift+DR means data transfer. On each rising edge of TCK, the data of TDI is shifted into the shift register, and the bit closest to TDO in the shift register is shifted to the TDO pin.

[0347] S602: If the current bit to be written is the last bit of the last byte of the data, the JTAG simulation module determines that the target level of the TMS pin is high.

[0348] When the JTAG emulation module simulates JTAG data writing, it checks whether the byte being written is the last byte of the data to be written after writing each byte. If the byte is not the last byte, the JTAG emulation module can execute step S605 and subsequent steps until the last bit of the byte is written. If the byte is the last byte, the JTAG emulation module can check whether the bit being written is the last bit of the byte after writing each bit. If the bit is the last bit of the byte, meaning the current bit to be written is the last bit of the last byte of data, the JTAG emulation module can pull the GPIO-emulated TMS high. In other words, when the JTAG emulation module writes the last bit of the last byte of the last data, it can determine that the target level of the TMS pin is high.

[0349] S603: The JTAG analog module sends a high-level indication to the acceleration module.

[0350] S604: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TMS pin.

[0351] It is understood that the specific implementation of steps S603-S604 can be referred to the relevant descriptions of steps S403-S404, and this application will not elaborate on them again.

[0352] S605: The JTAG simulation module determines the target level of the TDI pin based on the value of the current bit to be written.

[0353] After the JTAG simulation module triggers the acceleration module to write the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TMS pin, it can determine the target level of the TDI pin according to the value of the current bit to be written. If the current bit to be written is 0, the JTAG simulation module can determine that the target level of the TDI pin is low; if the current bit to be written is 1, the JTAG simulation module can determine that the target level of the TDI pin is high.

[0354] It is understood that the specific implementation of step S605 can be referred to the relevant description of step S405, and this application will not repeat it here.

[0355] S606: The JTAG simulation module sends information to the acceleration module to indicate the target level of the TDI pin.

[0356] S607: The acceleration module writes the preset value of the GPIO register corresponding to the target level of the TDI pin into the GPIO register corresponding to the TDI pin.

[0357] S608: The JTAG analog module determines that the target level of the TCK pin is low.

[0358] S609: The JTAG analog module sends information to the acceleration module to indicate a low level.

[0359] S610: The acceleration module writes the preset value of the GPIO register corresponding to the low level into the GPIO register corresponding to the TCK pin.

[0360] S611: The JTAG simulation module adds a delay based on the target operating frequency to the current working cycle.

[0361] S612: The JTAG simulation module determines that the target level of the TCK pin is high.

[0362] S613: The JTAG analog module sends a high-level indication to the acceleration module.

[0363] S614: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TCK pin.

[0364] It is understandable that the specific implementation of steps S606-S614 can be found in the relevant descriptions of steps S406-S414.

[0365] In some embodiments of this application, after the acceleration module executes step S614, the JTAG simulation module can execute step S611 to control the working cycle, so that the actual working frequency reaches the target working frequency.

[0366] It is understandable that if the data writing (i.e., writing data in units of 1 bit) is not completed after the acceleration module executes step S614, the JTAG simulation module and the acceleration module can execute steps S601-S614 again.

[0367] S615: The JTAG emulation and acceleration modules switch the JTAG state to Exit+IR until it returns to IDLE.

[0368] Similar to the write command, after the data writing is completed, the JTAG emulation module needs to switch the JTAG state to Exit+IR until it returns to IDLE. For the specific implementation method, please refer to the relevant description of step S415, which will not be repeated here.

[0369] S225: The JTAG emulation module enters the JTAG runtime test state. During the process of entering the JTAG runtime test state, the acceleration module is triggered to set the GPIO level.

[0370] After the JTAG simulation module simulates JTAG data writing, it can enter the JTAG runtime test state. A description of the JTAG runtime test state can be found in step S215, and will not be repeated here.

[0371] S226: The FPGA firmware upgrade service calls the FPGA vendor firmware upgrade protocol module to enable interrupts.

[0372] After the FPGA firmware upgrade service calls the interface of the corresponding FPGA vendor's firmware upgrade protocol to burn the first FPGA firmware, it can enable interrupts for the processor (e.g., CPU). It is understood that the relevant description of enabling interrupts can be found in step S219, and will not be repeated here.

[0373] As mentioned above, the FPGA firmware upgrade service can call the interface of the corresponding FPGA vendor's firmware upgrade protocol to repeatedly execute steps S221-S226 until the first FPGA firmware is completely burned into the FLASH of the FPGA device.

[0374] 3. After erasing and programming are complete, apply the first FPGA firmware and read the application status, then switch the state machine to the idle state (e.g., ...). Figure 9C (As shown).

[0375] S227: The FPGA vendor firmware upgrade protocol module disables interrupts.

[0376] After the FPGA firmware upgrade service erases the original FPGA firmware and burns the first FPGA firmware into the FPGA, the first FPGA firmware can be applied. First, the FPGA firmware upgrade service can call the corresponding FPGA vendor firmware upgrade protocol module, which can disable processor (e.g., CPU) interrupts.

[0377] It is understood that the relevant description of disabling interrupts can be found in step S212, and will not be repeated here.

[0378] S228: The FPGA vendor firmware upgrade protocol module triggers the application to write the first FPGA firmware into the FPGA's FLASH.

[0379] After interrupts are disabled, the FPGA vendor's firmware upgrade protocol module can trigger the JTAG emulation module to apply the first FPGA firmware written to the FPGA's FLASH. The JTAG emulation module can apply the first FPGA firmware written to the FPGA's FLASH by controlling the corresponding GPIO pins to emulate the JTAG protocol and write instructions to the FPGA, specifically including steps S229-S230.

[0380] S229: The JTAG emulation module simulates JTAG write commands. During the simulation of JTAG write commands, the acceleration module is triggered to set the GPIO level.

[0381] The JTAG simulation module writes the first FPGA firmware into the FPGA's FLASH memory, which can be achieved by simulating JTAG write commands. It is understood that the relevant description of the JTAG write commands can be found in step S214, and will not be repeated here.

[0382] As is understandable, the JTAG emulation module simulates JTAG write commands, and correspondingly, the FPGA in the electronic device can receive these commands. After the FPGA receives these commands, the first FPGA firmware can be applied.

[0383] S230: The JTAG emulation module enters the JTAG runtime test state. During the process of entering the JTAG runtime test state, the acceleration module is triggered to set the GPIO level.

[0384] After the JTAG emulation module simulates JTAG write commands, it can enter the JTAG runtime test state. A description of the JTAG runtime test state can be found in step S215, and will not be repeated here.

[0385] S231: Enable interrupt for FPGA vendor firmware upgrade protocol module.

[0386] After the FPGA firmware upgrade service calls the corresponding FPGA vendor firmware upgrade protocol module to apply the first FPGA firmware written to the FPGA's FLASH, the FPGA vendor firmware upgrade protocol module can enable interrupts for the processor (e.g., CPU). It is understood that the relevant description of enabling interrupts can be found in step S219, and will not be repeated here.

[0387] S232: The FPGA vendor firmware upgrade protocol module triggers the JTAG simulation module to read the application status of the first FPGA firmware.

[0388] After the FPGA firmware upgrade service calls the corresponding FPGA vendor's firmware upgrade protocol module to trigger the JTAG simulation module to write the first FPGA firmware into the FPGA, it can continue to call the corresponding FPGA vendor's firmware upgrade protocol module to trigger the JTAG simulation module to read the application status of the first FPGA firmware. The JTAG simulation module reads the application status of the first FPGA firmware by controlling the corresponding GPIO pins to simulate the JTAG protocol, writing instructions to the FPGA and reading data, which can be specifically achieved through steps S233 and S234.

[0389] S233: The JTAG emulation module simulates JTAG write commands. During the simulation of JTAG write commands, the acceleration module is triggered to set the GPIO level.

[0390] The JTAG simulation module reads the application status of the first FPGA firmware and can first simulate JTAG write commands. It is understood that the relevant description of the JTAG write commands can be found in step S214, and will not be repeated here.

[0391] As is understandable, the JTAG emulation module simulates JTAG write commands, and correspondingly, the FPGA in the electronic device can receive these commands. After receiving the commands, the FPGA can read the application status of the first FPGA firmware.

[0392] S234: The JTAG emulation module simulates JTAG data reading. During the simulated JTAG data reading process, the acceleration module is triggered to set the GPIO level.

[0393] After the JTAG emulation module simulates the JTAG write command, it can simulate the JTAG read data, thereby realizing the reading of the first FPGA firmware application state.

[0394] Similar to JTAG write commands and data writing, JTAG data reading can also involve multiple operations to set the GPIO level. This means that during the process of the JTAG emulation module simulating JTAG data reading, the JTAG emulation module can trigger the acceleration module to set the level of the corresponding GPIO pin.

[0395] The following is combined with Figure 10E This paper introduces a specific implementation method for simulating data reading using a JTAG simulation module.

[0396] Please see Figure 10E , Figure 10E A flowchart illustrating a method for simulating JTAG data reading, provided in an embodiment of this application. This method may include, but is not limited to, the following steps:

[0397] S701: The JTAG emulation and acceleration modules switch the JTAG state to Shift+DR.

[0398] Before the JTAG emulation module can emulate JTAG data reading, the JTAG state needs to be switched to Shift+DR. A description of Shift+DR can be found in step S601, and will not be repeated here. For specific instructions on switching the JTAG state, please refer to... Figure 10A Steps S301-S310 shown are not repeated here.

[0399] S702: When the JTAG analog module reads the last bit of the register value, it determines that the target level of the TMS pin is high.

[0400] When the JTAG emulation module reads the last bit of the JTAG register value in the FPGA, it can pull the GPIO-emulated TMS high. In other words, when the JTAG emulation module reads the last bit of the register value, it can determine that the target level of the TMS pin is high.

[0401] It should be noted that in some embodiments of this application, the JTAG simulation module can call the native level reading interface when reading the value of the JTAG register in the FPGA, without the need to use an acceleration module.

[0402] S703: The JTAG analog module sends information to the acceleration module to indicate a high level.

[0403] S704: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TMS pin.

[0404] It is understood that the specific implementation of steps S703-S704 can be referred to the relevant descriptions of steps S603-S604, and this application will not elaborate on them again.

[0405] S705: The JTAG analog module determines that the target level of the TCK pin is low.

[0406] S706: The JTAG analog module sends information to the acceleration module to indicate a low level.

[0407] S707: The acceleration module writes the preset value of the GPIO register corresponding to the low level into the GPIO register corresponding to the TCK pin.

[0408] S708: The JTAG simulation module adds a delay based on the target operating frequency to the current working cycle.

[0409] S709: The JTAG analog module determines that the target level of the TCK pin is high.

[0410] S710: The JTAG analog module sends information to the acceleration module to indicate a high level.

[0411] S711: The acceleration module writes the preset value of the GPIO register corresponding to the high level into the GPIO register corresponding to the TCK pin.

[0412] It is understandable that the specific implementation of steps S705-S711 can be found in the relevant descriptions of steps S406-S414.

[0413] In some embodiments of this application, after the acceleration module executes step S711, the JTAG simulation module can execute step S708, thereby controlling the working cycle so that the actual working frequency reaches the target working frequency.

[0414] S712: The JTAG analog module reads the level of the TDO pin and concatenates it as 1 bit of data.

[0415] After simulating the TCK level switch, the JTAG emulation module can read the level of the TDO pin and concatenate it as 1 bit of data. That is, for each time the JTAG emulation module reads the level of the TDO pin, it can obtain 1 bit of data, and concatenate the data obtained from reading the TDO pin level to obtain the complete data.

[0416] It is understandable that if the data reading is not completed after the acceleration module executes step S712, the JTAG simulation module and the acceleration module can execute steps S701-S712 again.

[0417] S713: The JTAG emulation and acceleration modules switch the JTAG state to Exit+DR until it returns to IDLE.

[0418] Similar to writing data, after completing the data reading, the JTAG simulation module needs to switch the JTAG state to Exit+DR until it returns to IDLE. For the specific implementation method, please refer to the relevant descriptions of steps S415 and S615, which will not be repeated here.

[0419] Understandably, Exit1-DR indicates the end of data transfer, preparing for updating the data in the data register.

[0420] S714: The JTAG simulation module returns complete data.

[0421] After the JTAG simulation module finishes reading the data, it can return the complete data.

[0422] S235: The JTAG simulation module returns the application status of the first FPGA firmware to the FPGA firmware upgrade service through the FPGA vendor firmware upgrade protocol module.

[0423] After the JTAG emulation module simulates JTAG data reading, it can use the FPGA vendor firmware upgrade protocol module to return the application status of the first FPGA firmware to the FPGA firmware upgrade service. If the returned application status indicates successful application, the FPGA firmware upgrade service can determine that the FPGA firmware upgrade is complete. If the returned application status indicates application failure, the FPGA firmware upgrade service can initiate a re-upgrade, i.e., attempt to upgrade the FPGA firmware again.

[0424] In some embodiments of this application, the number of times the FPGA firmware upgrade service is re-upgraded is equal to or less than the re-upgrade threshold. It is understood that the re-upgrade threshold can be set according to actual needs, and this application does not impose any restrictions on it. For example, the re-upgrade threshold can be 5.

[0425] S236: FPGA firmware upgrade service indicates that the state machine has switched to the idle state.

[0426] After the FPGA firmware upgrade service determines that the FPGA firmware upgrade is complete, it can instruct the state machine to switch its state to the idle state.

[0427] S237: The state machine acquires the state machine lock.

[0428] In response to the FPGA firmware upgrade service instructing the state machine to switch to the upgrade state, the state machine can acquire a state machine lock. If the state machine lock can be acquired, the state machine can continue to execute steps S238 and S239. If the state machine lock cannot be acquired, the state machine cannot switch to the idle state and must wait until the state machine lock is acquired before it can switch to the idle state.

[0429] S238: The state machine switches to the idle state.

[0430] After acquiring the state machine lock, the state machine can switch its state to the idle state.

[0431] S239: The state machine releases the state machine lock.

[0432] After the state machine switches to the idle state, the state machine lock can be released.

[0433] It is understood that the specific implementation of steps S236-S239 can be referred to steps S206-S209, and will not be repeated here.

[0434] S240: The FPGA firmware upgrade service triggers the switch of the FPGA's operating mode to runtime mode.

[0435] After switching the state machine to the idle state and releasing the state machine lock, the FPGA firmware upgrade service can trigger the switching of the FPGA's operating mode to the runtime mode. That is, the FPGA firmware upgrade service can trigger the setting of the level of the GPIO pin used to control the FPGA's operating mode, so that the FPGA's operating mode switches from firmware upgrade mode to runtime mode.

[0436] It is understood that the specific implementation of step S240 can be referred to step S210, and will not be repeated here.

[0437] S241: FPGA firmware upgrade service notification OTA engine FPGA firmware upgrade completed.

[0438] Once the FPGA firmware upgrade service confirms that the firmware upgrade is complete, it can notify the OTA engine that the FPGA firmware upgrade is complete.

[0439] It is understood that this application does not restrict the order of steps S236 and S241. Step S241 may be performed before step S236.

[0440] S242: The OTA engine prompts the user that the FPGA firmware upgrade is complete.

[0441] After the FPGA firmware upgrade service notifies the OTA engine that the upgrade is complete, the OTA engine can notify the user that the upgrade is complete. Similar to step S203, the OTA engine can trigger the electronic device to display a prompt box or notify the user of the FPGA firmware upgrade completion via voice announcement. This application does not limit the method of notification.

[0442] It is understood that the specific write instructions involved in the JTAG emulation module's simulation of write instructions in steps S214, S217, S223, S229, and S233 are different; that is, the values ​​of the bits to be written are different in the above steps. For example, the write instruction involved in step S214 is 0x05, while the write instruction involved in step S217 is 0x71.

[0443] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An FPGA firmware upgrade method, characterized in that, The method is applied to an electronic device including an FPGA device and multiple GPIO pins, and the method includes: Receive the first FPGA firmware sent by the cloud server; If the upgrade is confirmed and the first FPGA firmware meets the first preset condition, M GPIO pins among the plurality of GPIO pins are controlled to simulate JTAG signal lines to upgrade the firmware of the FPGA device to the first FPGA firmware; M is a positive integer. During the process of upgrading the firmware of the FPGA device to the first FPGA firmware, the simulated JTAG operating frequency is kept in accordance with the JTAG standard operating frequency defined by the hardware specifications.

2. The method as described in claim 1, characterized in that, The M GPIO pins include a first GPIO pin; controlling the M GPIO pins among the plurality of GPIO pins to simulate JTAG signal lines to upgrade the firmware of the FPGA device to the first FPGA firmware specifically includes: The M GPIO pins are controlled to simulate JTAG signal lines to erase the original FPGA firmware, burn the first FPGA firmware into the FPGA device, and apply the first FPGA firmware in the FPGA device. In the process of erasing the original FPGA firmware, burning the first FPGA firmware to the FPGA device, and applying the first FPGA firmware in the FPGA device, if it is necessary to set the level of the first GPIO pin to a target level, a first preset value is written to the first register; the first preset value is the GPIO register preset value corresponding to the target level, and the target level is a high level or a low level; the first register is the register corresponding to the first GPIO pin.

3. The method as described in claim 1 or 2, characterized in that, During the process of upgrading the firmware of the FPGA device to the first FPGA firmware, when setting the level for any one or more GPIO pins among the M GPIO pins, maintenance information related to accessing the registers corresponding to the M GPIO pins is not stored.

4. The method according to any one of claims 1-3, characterized in that, The electronic device further includes a state machine; before controlling M GPIO pins among the plurality of GPIO pins to simulate JTAG signal lines to upgrade the firmware of the FPGA device to the first FPGA firmware, the method further includes: If the upgrade is confirmed and the first FPGA firmware meets the first preset condition, the state machine is switched to the first state, and the process of switching to the first state is protected by a lock. When the state machine is in the first state, the electronic device is in the process of upgrading the firmware of the FPGA device through the upgrade interface; the upgrade interface is an interface simulated by the electronic device through the M GPIO pins.

5. The method as described in claim 4, characterized in that, Switching the state of the state machine to the first state specifically includes: If the state machine is in the second state, switch the state machine from the second state to the first state. If the state machine is in the third state, continue until the state machine becomes the second state before switching the state machine back to the first state. When the state machine is in the second state, the electronic device is not in the process of configuring the FPGA device through the control interface; when the state machine is in the third state, the electronic device is in the process of configuring the FPGA device through the control interface.

6. The method as described in claim 4 or 5, characterized in that, After switching the state of the state machine to the first state, the method further includes: By setting the levels of N GPIO pins among the plurality of GPIO pins, the operating mode of the FPGA device is switched to the first mode; when the operating mode of the FPGA device is the first mode, the FPGA device performs firmware upgrades through the upgrade interface; N is a positive integer.

7. The method according to any one of claims 4-6, characterized in that, After upgrading the firmware of the FPGA device to the first FPGA firmware, the method further includes: Switch the state machine to the second state; By setting the levels of N GPIO pins among the plurality of GPIO pins, the operating mode of the FPGA device is switched to the second mode; when the operating mode of the FPGA device is the second mode, the FPGA device does not perform firmware upgrades through the upgrade interface; N is a positive integer.

8. The method according to any one of claims 4-7, characterized in that, Before receiving the first FPGA firmware sent by the cloud-side server, the method further includes: In response to the operation of activating the electronic device, the following initialization process is performed: Obtain the M GPIO pins used to simulate JTAG signal lines and initialize them; Obtain the N GPIO pins used to control the operating mode of the FPGA device and initialize them; Initialize the state machine and state machine lock, and set the state of the state machine to the second state; Obtain and initialize the clock and power supply of the FPGA device.

9. The method according to any one of claims 1-8, characterized in that, During the process of upgrading the firmware of the FPGA device to the first FPGA firmware, maintaining the simulated JTAG operating frequency in accordance with the JTAG standard operating frequency defined by the hardware specifications specifically includes: During the process of upgrading the firmware of the FPGA device to the first FPGA firmware The updated working cycle is obtained by adding a first delay to the current working cycle; the updated working cycle is the reciprocal of the target working frequency. The target operating frequency conforms to the JTAG standard operating frequency defined in the hardware specifications.

10. An electronic device, characterized in that, The electronic device includes an FPGA device, one or more memories, and one or more processors; the FPGA device, the one or more memories, and the one or more processors are coupled together; the processors include a plurality of GPIO pins for simulating JTAG signal lines; the memories are used to store computer program code, the computer program code including computer instructions; and the processors call the computer instructions to execute the method of any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, Used to store computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in any one of claims 1-9.

Images