Card opening method and electronic device

Abstract

The application discloses a kind of card opening method and electronic equipment of storage medium technical field, obtain the file size of card opening firmware, according to the file size of the card opening firmware increase the partition size of mirror image configured in boot loader;In the program compilation of bus function that is started in the configuration corresponding to boot loader;In the card opening firmware is burned to obtain card opening data in the execution stage of the boot loader, and the card opening data is sent to the card to be opened in the card to be opened by the bus function, and the card opening of the card to be opened is completed.The application does not need to place the card to be opened in special card opening tool, and boot loader can be easily transplanted between the platform supporting boot loader start, to save development cost.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of storage media, in particular to a card opening method and electronic device. BACKGROUND

[0002] When a disc is used for the first time or card opening fails, the disc needs to be operated to open the card so that the disc can work normally. The traditional card opening method relies on an upper computer, an img file (mirror file), an operating system, a card opening mold, an adapter and the like, and the steps are complicated. For example, an upper computer application program needs to be developed on a Linux operating system or a Windows operating system to implement burning of the img file on the disc, and different card opening molds need to be customized for different disc shapes, the card opening mold is combined with the adapter to realize connection with the upper computer, and in the card opening process, the disc in the store needs to be manually powered on and powered off, and the disc that has been welded on the product needs to be disassembled. SUMMARY

[0003] The present application solves the technical problem of providing a card opening method and electronic device to realize a more efficient card opening process.

[0004] In order to solve the above technical problems, the technical scheme adopted by the present application is:

[0005] A card opening method, comprising:

[0006] Obtaining the file size of a card opening firmware, increasing the partition size of an image configured in a bootloader according to the file size of the card opening firmware;

[0007] Compiling a program that enables bus function in the configuration corresponding to the bootloader;

[0008] Burning the card opening firmware to obtain card opening data in the execution stage of the bootloader, and sending the card opening data to a disc to be opened through the bus function to complete the card opening of the disc to be opened.

[0009] In order to solve the above technical problems, another technical scheme adopted by the present application is:

[0010] An electronic device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements each step of the above card opening method when executing the computer program.

[0011] The beneficial effect of the present application is that the size of the image partition configured in the bootloader is increased according to the file size of the card opening firmware, so as to avoid the overflow of data in the image partition after the card opening firmware is burned in the bootloader execution stage, and the program compilation of the bus function is started in the configuration corresponding to the bootloader, so that the card to be opened can be accessed and data interaction is performed with the card to be opened through the bus function in the bootloader execution stage, so as to complete the sending of the card opening data and the execution of the card opening process. In this way, the bootloader is modified, so that the card opening process can be completed in the execution stage of the bootloader, thereby widening the execution environment of the card opening program, and the card opening process in the bootloader execution stage can be completed based on the client finally required to be run on the card to be opened. The card to be opened does not need to be placed in a special card opening tool, and the bootloader can be easily transplanted between platforms supporting the bootloader startup, thereby saving the development cost. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 A step flowchart of a card opening method in an embodiment of the present application;

[0013] Figure 2 A flowchart of card opening data alignment transmission in an embodiment of the present application;

[0014] Figure 3 A schematic diagram of card opening data alignment in an embodiment of the present application;

[0015] Figure 4 A step flowchart of implementing card opening data alignment transmission in an embodiment of the present application;

[0016] Figure 5 A step flowchart of implementing a card opening method in an eMMC scenario in an embodiment of the present application;

[0017] Figure 6 A structural schematic diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0018] To explain the technical content, the achieved purposes and effects of the present application in detail, the following will be explained in combination with the embodiments and the accompanying drawings.

[0019] A card opening method, comprising:

[0020] Obtaining the file size of the card opening firmware, and increasing the partition size of the image configured in the bootloader according to the file size of the card opening firmware;

[0021] Starting the program compilation of the bus function in the configuration corresponding to the bootloader;

[0022] The card opening data is obtained by burning the card opening firmware in the boot loader execution stage, and the card opening data is sent to the card to be opened through the bus function to complete the card opening of the card to be opened.

[0023] From the above description, the beneficial effects of the present application are that the size of the mirror partition configured in the boot loader is increased according to the file size of the card opening firmware, which avoids the overflow of data in the mirror partition after the card opening firmware is burned in the boot loader execution stage, and the program compilation of the bus function is started in the corresponding configuration of the boot loader, so that the card to be opened can be accessed and data interaction is performed with the card to be opened through the bus function in the boot loader execution stage, to complete the sending of the card opening data and the execution of the card opening process. The boot loader is thus modified, so that the card opening process can be completed in the boot loader execution stage, thereby widening the execution environment of the card opening program, and the card opening process in the boot loader execution stage can be completed based on the client that needs to be finally run on the card to be opened, without the need to place the card to be opened in a special card opening tool, and the boot loader can be easily ported between platforms that support boot loader startup, thereby saving development costs.

[0024] Further, it also includes:

[0025] If the card to be opened is an eMMC, the capacity value to be written into the eMMC is calculated according to the card opening capacity level of the eMMC, and the capacity value is written into the card opening firmware;

[0026] The check value of the card opening firmware is updated.

[0027] From the above description, in the case of an eMMC card to be opened, the capacity value to be written into the eMMC is calculated according to the card opening capacity level of the eMMC, and the capacity value is written into the card opening firmware. When the boot loader is executed, the capacity value of the eMMC is set correspondingly, and the user can only use the set capacity value, thereby reserving system capacity for the system firmware in the eMMC to ensure that the programs in the system firmware can be normally executed to realize the configuration of the card opening process.

[0028] Further, if the card to be opened is a solid state disk, the macro definition switch of the solid state disk is started in the corresponding configuration of the boot loader, so that the card opening program can complete data interaction with the solid state disk through the macro definition in the boot loader execution stage.

[0029] From the above description, if the card to be opened is a solid state disk, the macro definition switch of the solid state disk is started in the corresponding configuration of the boot loader, so that the solid state disk can be configured to complete data interaction in the boot loader execution stage, and the execution of the card opening process is supported.

[0030] Further, the method further comprises:

[0031] shielding the reference of the boot loader to the kernel layer, and deleting the jump function of the boot loader jumping to the folder corresponding to the kernel layer;

[0032] adding the device tree driver corresponding to the bus function in the device tree driver corresponding to the boot loader, and adding the device tree node of the power-on control of the bus function to the hardware configuration information of the execution stage of the boot loader in the device tree source file, so that the bus function is used in the execution stage of the boot loader.

[0033] As can be seen from the above description, the reference of the boot loader to the kernel layer is shielded, and the jump function of the boot loader jumping to the folder corresponding to the kernel layer is deleted, so as to avoid jumping to the kernel startup stage before the card opening process is completed. The device tree driver corresponding to the bus function is added in the device tree driver corresponding to the boot loader, so as to activate the corresponding device tree node to complete the power-on of the bus function in the execution stage of the boot loader, and the bus function can be used in the execution stage of the boot loader, so as to complete the data interaction with the card to be opened to realize the card opening process.

[0034] Further, the method further comprises:

[0035] writing the card opening program in the last list item of the startup list of the boot loader;

[0036] When the card opening program is executed, the card opening data obtained by burning the card opening firmware is sent to the card to be opened through the bus function to complete the card opening of the card to be opened.

[0037] As can be seen from the above description, the card opening program is written in the last list item of the startup list of the boot loader, so that when the card opening program is executed, it can be ensured that all peripheral devices are ready during the execution of the card opening process, that is, the original code of the boot loader is used to complete the initialization of the system to provide an execution basis for the card opening program, and there is no need to build a card opening platform from scratch.

[0038] Further, the sending of the card opening data to the card to be opened through the bus function comprises:

[0039] aligning the card opening data with the minimum read-write unit of the solid state disk through the bus function, and sending the card opening data to the solid state disk.

[0040] From the above description, it can be known that, after aligning the card opening data with the minimum read-write unit, the card opening data is transmitted, so that the analysis process in the process of reading the card opening data is reduced, and the execution efficiency of the card opening program is improved.

[0041] Further, the minimum read-write unit of the solid state disk is obtained, the card opening data is aligned with the minimum read-write unit through the bus function, and the card opening data is transmitted into the solid state disk, including:

[0042] A first pointer position in the memory cache of the solid state disk is obtained, and it is judged whether the first pointer position is offset from the minimum read-write unit;

[0043] If yes, the first pointer position is offset to the starting position of the minimum read-write unit, and the card opening data is transmitted into the solid state disk through the direct memory access mode according to the first pointer position;

[0044] Otherwise, the card opening data is directly transmitted out of the solid state disk through the direct memory access mode according to the first pointer position.

[0045] From the above description, by writing data into the memory cache of the solid state disk through the direct memory access mode, the efficiency of data transmission is improved, and before data transmission, it is judged whether the first pointer position in the memory cache is offset from the minimum read-write unit, if yes, the pointer is offset to the starting position of the minimum read-write unit, in this way, when the card opening data is transmitted, it can be stored in the complete minimum read-write unit, the number of times of updating the next minimum read-write unit for data reception in the process of transmitting data is reduced, and the efficiency of transmitting the card opening data is improved.

[0046] Further, it further includes:

[0047] The bus function offload driver and the disk offload driver are written in the bootloader;

[0048] When the card opening of the to-be-opened disk is completed, the bus function is unloaded according to the bus function offload driver, and the to-be-opened disk is unloaded according to the disk offload driver.

[0049] From the above description, the bus function offload driver and the disk offload driver are written in the bootloader, so that if the bus function needs to be unloaded or the to-be-opened disk needs to be unloaded during the card opening process, the bus function or the to-be-opened disk does not need to be powered off through a physical method, but can be directly powered off through the bus function offload driver and the disk offload driver, and the to-be-opened disk does not need to be disassembled.

[0050] Further, the sending of the card opening data to the to-be-opened card through the bus function and the completion of the card opening of the to-be-opened card include:

[0051] The core power supply and the input and output power supply of the eMMC are reset, and a cmd61 is sent to the eMMC, so that the eMMC enters a read-only code mode.

[0052] The eMMC is sequentially sent a cmd0, a cmd1, a cmd2, a cmd3, a cmd9 and a cmd7 to complete an initialization process.

[0053] The communication parameters of the eMMC are set through a cmd16.

[0054] The eMMC is made to enter a preparation update state through a cmd60.

[0055] The card opening data is sent to the eMMC through a cmd25 and a cmd12.

[0056] Whether the card opening data is normally received by the eMMC is confirmed through a cmd13, if yes, the core power supply and the input and output power supply of the eMMC are reset, and the eMMC is sequentially sent a cmd0, a cmd1, a cmd2, a cmd3, a cmd9 and a cmd7 to complete an initialization process.

[0057] From the above description, for the case that the to-be-opened card is an eMMC, the state of the eMMC is changed and confirmed through the sending of a cmd command to the eMMC, so as to realize the sending of the card opening data and the judgment of whether the card opening data is normally received, and the card opening process is completed through the initialization process of the eMMC by the cmd command, without the need of disassembling the eMMC, and the card opening process can be completed based on the boot loader execution stage of the device carrying the eMMC, and the application program loaded after the complete start of the Android system is not needed.

[0058] Another embodiment of the present application provides an electronic device, including a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements each step of the card opening method when executing the computer program.

[0059] In the mass production process of device products, there are a few products using the disc which has the burned firmware damaged, burned failure and the like. According to the traditional method, the disc module is taken from the customer product to re-open the card through the mold. In the process of the disc being unable to work, the master control chip of the device product is in the uboot state. If the uboot state of the master control can be used to open the card of the disc driven by the product, a large part of the process can be reduced, the efficiency of the product mass production rework and after-sales problem processing can be improved, and the after-sales cost can be reduced.

[0060] Based on this, the application further provides an opening card method and electronic equipment which can be applied to the scene in which the disc needs to be opened, especially the scene in which the disc has been assembled on the device. The opening card process is independent of the specific platform and mold, the dependence of the opening card process on the external environment is reduced, and the opening card process is simplified to improve the efficiency in the mass production and after-sales process. The following is described through the specific embodiment.

[0061] Embodiment one

[0062] An opening card method, please refer to Figure 1 , comprising steps S1 to S3.

[0063] S1, obtain the file size of the opening card firmware, and increase the partition size of the image configured in the boot loader according to the file size of the opening card firmware.

[0064] S2, compile the program of starting the bus function in the corresponding configuration of the boot loader.

[0065] In an optional embodiment, S3 includes S21 before S3: converting the opening card firmware to be burned into hexadecimal data, such as converting the fw file to be burned into hexadecimal data after the fw file to be burned is required. The image volume generated by the uboot is made larger, so the partition size of the image configured in the uboot needs to be modified correspondingly to make the corresponding partition size after the uboot is burned can store the burned fw file.

[0066] S3, burn the opening card firmware to obtain opening card data in the execution stage of the boot loader, and send the opening card data to the disc to be opened through the bus function to complete the opening card of the disc to be opened.

[0067] In an optional embodiment, in S3, the opening card data is sent to the disc to be opened through the bus function, including S301: obtaining the minimum read-write unit of the solid state disk, aligning the opening card data with the minimum read-write unit through the bus function, and sending the opening card data to the solid state disk.

[0068] In an optional implementation, S301 comprises S3011-S3013.

[0069] S3011, acquire a first pointer position in a memory cache of the solid state disk, determine whether the first pointer position and the minimum read-write unit exist an offset, if yes, execute S3012, otherwise execute S3013.

[0070] S3012, offset the first pointer position to a start position of the minimum read-write unit, and send the card opening data into the solid state disk by a direct memory access mode according to the first pointer position.

[0071] S3013, directly send the card opening data out of the solid state disk by a direct memory access mode according to the first pointer position.

[0072] In an optional implementation, if the DMA controller is a double buffer mode, S3012 further comprises: acquiring a second pointer position, and after the second pointer position points to the start position of the minimum read-write unit, continuing the subsequent program; S3013 further comprises: acquiring a current position of the second pointer position, and then continuing the subsequent program.

[0073] In an optional implementation, it further comprises S01: if the to-be-card opening disk is an eMMC, calculating a capacity value needed to be written into the eMMC according to a card opening capacity level of the eMMC, and writing the capacity value into a card opening firmware; and updating a check value of the card opening firmware. The above S01 can be executed before S1, so as to ensure the accuracy of the file size of the card opening firmware acquired in S1.

[0074] In an optional implementation, it further comprises S02: if the to-be-card opening disk is a solid state disk, turning on a macro definition switch of the solid state disk in a configuration corresponding to a boot loader, so that the card opening program completes data interaction with the solid state disk through a macro definition in a boot loader execution stage. The above S02 can be executed simultaneously with S2, that is, when the boot loader is configured and modified, the bus function related configuration and the configuration of the solid state disk are simultaneously modified, so that the card opening data can be sent into the solid state disk through the bus function in the boot loader execution stage, and the solid state disk can be programmed through the macro definition to realize necessary settings in the card opening process.

[0075] In an optional implementation, it further comprises S03-S04.

[0076] S03, shield the reference of the boot loader to the kernel layer, and delete a jump function of a folder corresponding to the jump of the kernel layer of the boot loader.

[0077] S04, adding a bus function corresponding device tree driver in the device tree driver corresponding to the bootloader, and adding a power-on control device tree node of the bus function on the hardware configuration information corresponding to the bootstrapping bootloader execution stage in the device tree source file, so that the bus function is started in the bootstrapping bootloader execution stage.

[0078] The above S03 to S04 can be executed between S2 and S3, and after the program for starting the bus function is compiled, the bus function corresponding device tree driver is added in the bootstrapping bootloader, and the power-on control device tree node of the bus function is added on the hardware configuration information corresponding to the bootstrapping bootloader execution stage, so that the bus function can be successfully started in the bootstrapping bootloader execution stage to complete the data interaction with the to-be-opened disk. The bus function can be a PCI bus or a PCIe bus, which is not limited here.

[0079] In an optional embodiment, S311 to S312 are further included.

[0080] S311, writing an open card program in the last list item of the startup list of the bootstrapping bootloader.

[0081] S312, when the open card program is executed, burning the open card firmware to obtain open card data, and sending the open card data to the to-be-opened disk through the bus function to complete the opening of the to-be-opened disk.

[0082] The above S311 and S312 can be a specific implementation of S3, that is, the steps in S3 are the steps executed in the open card program. The open card program is executed as the last execution item of the bootstrapping bootloader, so that the bus function configured by the bootstrapping bootloader can be used to realize the open card process.

[0083] In an optional embodiment, S05 to S06 are further included.

[0084] S05, writing a bus function uninstallation driver and a disk uninstallation driver in the bootstrapping bootloader.

[0085] S06, when the opening of the to-be-opened disk is completed, uninstalling the bus function according to the bus function uninstallation driver, and uninstalling the to-be-opened disk according to the disk uninstallation driver.

[0086] The above S05 to S06 can be executed before S3, so that if the bus function needs to be uninstalled or the to-be-opened disk needs to be uninstalled during the execution of the open card program, the corresponding uninstallation driver can be directly used for uninstallation, without the need for physical uninstallation.

[0087] In an alternative embodiment, the sending of the card opening data to the card to be opened through the bus function in S3 includes S321-S326.

[0088] S321, reset the core power supply and the input / output power supply of the eMMC, and send cmd61 to the eMMC, so that the eMMC enters a read-only code mode;

[0089] S322, sequentially send cmd0, cmd1, cmd2, cmd3, cmd9 and cmd7 to the eMMC to complete the initialization process;

[0090] S323, set the communication parameters of the eMMC through cmd16;

[0091] S324, make the eMMC enter a preparation update state through cmd60;

[0092] S325, send the card opening data to the eMMC through cmd25 and cmd12;

[0093] S326, confirm whether the card opening data is normally received by the eMMC through cmd13, if yes, reset the core power supply and the input / output power supply of the eMMC, and sequentially send cmd0, cmd1, cmd2, cmd3, cmd9 and cmd7 to the eMMC to complete the initialization process.

[0094] In an alternative embodiment, S3 is followed by S4: return to the execution flow of the bootloader. In this way, after the card opening is completed, the execution flow of uboot is returned, and the system booting process is normally implemented.

[0095] Embodiment Two

[0096] The above-mentioned card opening method is applied to an actual scenario, for example, the card to be opened is a solid state disk (SSD), including an NVMe (Non-Volatile Memory Express) SSD, and the solid state disk is mounted on a production device, which can be a production device based on an ARM (Acorn RISC Machine, Advanced RISC Machine) architecture, for example, a production device based on an RK3588 platform. The production device is a device finally delivered to a user, for example, various handheld terminals, etc. The method includes the following steps.

[0097] (1) Modify the config file in the SDK (Software Development Kit) of uboot (boot loader). Thus, uboot can be successfully compiled, and the related programs of PCIe and NVMe can be executed in the uboot execution stage.

[0098] Specifically, the partition size of the uboot image in the config file needs to be modified. Please refer to Figure 2 It can be seen that the card opening img (image file, equivalent to card opening data) needs to have a certain storage space, for example, it needs 2M of space, and the size of the partition corresponding to the default uboot is 4M, so if the card opening data is implanted, it will cause the data of the uboot corresponding partition to overflow, so the image partition size needs to be increased according to the size of the card opening firmware. Equivalent to step S1 above.

[0099] And, the PCI function and NVMe macro definition switch of uboot need to be opened in deconfig. Equivalent to steps S2 and S02 above.

[0100] Wherein NVMe is a logical device interface specification, the full name is Non-Volatile Memory Host Controller Interface Specification, which is used to access non-volatile storage media through PCIe bus, that is, to start the bus function PCIe in the uboot execution stage.

[0101] (2) Convert the card opening firmware required for opening the solid state disk into an array of hexadecimal. For example, in the process of opening the SSD twice, the corresponding fw file needs to be burned, so the fw file needs to be converted into hexadecimal data and burned with the uboot program, which is the main reason for the increase in the volume of the image generated by uboot. Equivalent to S21 above.

[0102] (3) Modify uboot to drive the related devices of PCI alone. If the platform uboot has complete drivers for PCIe card slots, this step can be skipped. This step is to make the single uboot have a complete device tree configuration file about PCIe, without referencing the device tree file of other layers, so as to maintain in the uboot stage.

[0103] Specifically, the dtb macro definition and related reference program of kernel (kernel) layer about PCI are shielded, and the jump function of dtb_embed is deleted in the uboot / arch / arm / mach-rochip / kernl_dtb.c file, so as not to reference the device tree file in the kernel folder. Equivalent to S03 above.

[0104] And, add the device tree driver about PCI in the device tree driver of uboot, add the device tree node about the power-on control of PCIe in the uboot / arch / arm / dts / rk3588-u-boot.dtsi file, so that PCIe can be powered on and work normally at the uboot layer. It is equivalent to S04 described above.

[0105] (4) Add the card opening program in uboot. For example, write the card opening process program into the last list item in the uboot list startup, so as to ensure that other peripheral devices are ready during the card opening process. It is equivalent to S311 described above.

[0106] In the above steps, for adding the card opening program in uboot, the following two details about the instruction format are needed:

[0107] a, please refer to Figure 2 , page number judgment of card opening data transmission: there are two pages of data transmission pointers in the uboot card opening process, which need to be guaranteed to point to 4K (the smallest read-write unit) aligned positions. In solid state disks, the smallest read-write unit is usually one page (4K).

[0108] b, please refer to Figure 3 , address alignment of data transmission: guaranteeing that the address of sending card opening data is 4K aligned can reduce the page judgment of the program and speed up the card opening process.

[0109] For example, please refer to Figure 4 to judge whether the currently transmitted data needs to be paged. There are two pointers P1 and P2 in NVMe transmission pointing to the DMA storing the card opening data to ensure the alignment of data transmission; in addition, the address of the DMA transmission card opening data transmission variable needs to be 4K aligned. Since the number of sent card opening data packets is large, the cyclic use of a 4K aligned variable by memalign (a function for dynamically allocating memory) can make the effect better, and this way can make the data transmission of NVMe almost like Figure 3 "no need to page". It is equivalent to S3011 to S3013 described above.

[0110] (5) Reload the drivers of PCIe and NVMe during the first card opening and the second card opening.

[0111] After the first card opening process is completed, before the second card opening starts, the PCIe and NVMe driver loading operation needs to be performed in the card opening process.

[0112] The initialization operation of the PCIe driver can be performed immediately after the first card opening is completed.

[0113] The program of the self-provided uboot does not have PCIe and NVMe offloading drivers, and the function offloading entry for PCI and NVMe needs to be manually added, so that the effect of loading after offloading is equivalent to the state when uboot is booting. For example, the PCIE drive offloading function is added in uboot / drivers / pci / pci-uclass.c; the NVME drive offloading function is added in uboot / drivers / nvme / nvme.c; and the functions are uniformly called after the first card opening process is completed. In this way, in the traditional card opening process, the disk needs to be powered on and off. The uboot card opening powers on and off the disk only by controlling the power supply (offloading) of the PCIe card slot, and the offloading of NVMe also meets the protocol from top to bottom. Since the subsequent data needs to be transmitted through PCIe, the PCI driver is loaded again. It is equivalent to S05 and S06 described above.

[0114] (6) The program of the source code of uboot returned after the card opening program execution is completed, that is, the end of the card opening process.

[0115] Embodiment Three

[0116] Please refer to Figure 1 and Figure 2 The difference between the above-mentioned embodiments is that the above-mentioned card opening process is applied to eMMC, and eMMC is installed in an Android system platform. In modern electronic devices, eMMC (Embedded Multi Media Card, embedded storage) is widely used as a storage device; and the software program running inside the eMMC chip is called firmware. After the storage chip is produced, the storage chip has not been pasted, a series of jigs will be used to burn the firmware of the single storage chip, and a series of checks and tests will be performed, which is called card opening. When the eMMC chip is produced, it can only be opened through a specific jig. This method has the following disadvantages: after the chip is pasted to the mainboard, the chip needs to be removed and soldered to the specific jig for card opening, and the high-temperature operation of removing and soldering is easy to cause physical damage to the chip or shorten the service life of the chip. For example, eMMC chips are used in Android platforms, and during testing, the firmware is abnormal, the machine cannot be started, and the Android system cannot be recovered. When the eMMC chip particles need to be removed and soldered to be re-opened, the operation is complicated and easy to cause damage to the chip.

[0117] The opening card operation of the eMMC is to completely format the eMMC through a series of commands and complete the version update of the internal running code of the eMMC. In the related art, after the eMMC completes the opening card operation, there is an attempt to update the firmware in the eMMC through the installation of an application program in the Android system, but this way cannot realize the opening card process of the eMMC, because the eMMC is in the ROM Code running state when the opening card is performed, at which time the request from the system will time out; the operation of the eMMC in the application program depends on the ioctl interface, which is opened by the kernel MMC driver to the upper layer application, once the eMMC enters the ROM Code state, the MMC driver cannot normally communicate with the eMMC; therefore, the way of interacting with the eMMC through the application program can only query some information of the eMMC, read and write commands, or perform ffu (the firmware update of the eMMC will not enter the ROM Code state).

[0118] An opening card method comprises the following steps.

[0119] (1) Configure the opening card capacity level of the eMMC in the bootloader. It is equivalent to S01 described above.

[0120] The eMMC capacity value is not written in the eMMC firmware, but is configured during the opening card operation, because the opening card capacity level corresponding to different sizes of eMMC is different. The opening card capacity level includes 1-8, which respectively correspond to 8G, 16G, 32G, 64G, 128G, 256G, 512G and 1T different eMMC total capacity values, and different eMMC total capacities correspond to different capacity values. The capacity value is the user capacity of the eMMC, for the eMMC, the total capacity includes the system capacity occupied by the system and the user capacity available to the user, after configuring the capacity value, enough space is reserved for the installation of the system firmware, to ensure that the eMMC can be normally used after opening card. As long as the Android system software can normally boot and is equipped with a normal eMMC chip, it can normally enter the bootloader stage (uboot stage) during the booting process after flashing.

[0121] The opening card capacity level is limited by the Nand hardware of the eMMC, here the capacity value configured according to the opening card capacity level needs to be preset in advance to ensure the performance of the firmware. For example, the eMMC limits the total capacity to 8G, the firmware may preset 7296MB as the user capacity available to the user, and the remaining space is used as the space required for the internal running of the firmware. 7296MB is the capacity value corresponding to the opening card capacity level 1. The capacity value corresponding to the capacity level can also be calculated through a logical shift formula, shifting n bits to the left is equivalent to multiplying the original number by 2 n . Therefore, the formula can be transformed as: capacity value = 7634944 × 2 (容量等级-1) .

[0122] When the capacity level is 2, the number of shifts is 2-1=1; the capacity value is 7634944<<1=7634944*2 1 =15269888KB, that is, for an eMMC with a total capacity of 16G, the capacity value is set to 14.5625G. Different base values can be set for different capacity levels, for example, when the capacity level is 1, the base value used is 7471104KB, which corresponds to 7296MB. In this way, a more reasonable capacity value can be determined for each capacity level.

[0123] (2) Calculate the capacity value that needs to be written into the eMMC according to the card opening capacity level, and write the capacity value into the update firmware bin. This corresponds to S01 described above.

[0124] In an optional embodiment, S120 includes: obtaining data partition information corresponding to the capacity value information in the update firmware, recalculating the check value of the data partition information and the check value of the update firmware after modifying the data partition (ISP, Initial System Program, code segment in eMMC, each ISP partition stores different function code) information according to the capacity value. In the first kilobyte data of the update firmware bin, the ISP partition information of the firmware can be obtained. Here, the capacity value needs to be modified to modify the data of the 212th offset address of the ISP27 and ISP29 two ISP partitions, with a length of 4 bytes. The specific position here can be read from the header configuration data of the update firmware. This is only an example. After modifying the ISP partition information according to the capacity value, the check values of the modified ISP27 and ISP29 two partitions are recalculated, and the check value of the entire update firmware bin is recalculated to achieve tamper-proofing and ensure the security of the update firmware bin.

[0125] In an optional embodiment, S130 includes: after the Android system is started, configuring the eMMC to enter the read-only code mode in the bootloader execution stage, and then executing an initialization command flow on the eMMC.

[0126] (3) After starting, the eMMC is configured to complete card opening according to the card opening capacity level and the update firmware in the bootloader execution stage. This corresponds to the steps of the card opening program executed in S312 when the card to be opened is an eMMC.

[0127] In an optional embodiment, (2) is followed by: saving the update firmware in the Android system; and (3) includes (3-1) to (3-2).

[0128] (3-1) configuring the user capacity of the eMMC according to the card opening capacity level in the bootloader execution stage. Then the total capacity of the eMMC minus the user capacity is the system capacity, and the firmware is installed in the system capacity, for example, the range of the user capacity and the system capacity can be identified by a memory pointer to limit the range of the storage space that the user and the system firmware can access.

[0129] (3-2) downloading the update firmware into the eMMC to make the eMMC install the update firmware.

[0130] In an optional embodiment, the update firmware is downloaded into the eMMC by the Cmd25+Cmd12 instruction. This corresponds to S325 above.

[0131] In an optional embodiment, the (3-2) includes: after downloading the update firmware into the eMMC, sending a check instruction (Cmd13) to the eMMC to confirm whether the update firmware is normally received, and if so, executing an initialization command process on the eMMC to make the eMMC install the update firmware to complete the card opening. This corresponds to S326 above.

[0132] In an optional embodiment, S132 is followed by: after configuring the identifier (CID) of the eMMC, executing an initialization command process on the eMMC to make the eMMC persistently store the identifier. The CID includes a vendor identifier, an application identifier, etc.; the CID can uniquely identify the eMMC, so that in the scenario of multiple memories, the system can accurately access the required eMMC according to the CID.

[0133] In an optional embodiment, (3) includes (3-3) to (3-4).

[0134] (3-3) the Android system completes a hardware initialization process to obtain the hardware driver of the eMMC in the bootloader execution stage.

[0135] (3-4) writing the card opening capacity level and the update firmware into the eMMC by calling the hardware driver. That is, the above steps (3-1) to (3-2) can be implemented by calling the hardware driver in the bootloader execution stage.

[0136] In an optional embodiment, the above execution of the initialization command process on the eMMC includes: after resetting the power supply of the eMMC, executing the initialization command process on the eMMC. This corresponds to S321 and S322 above.

[0137] In an alternative embodiment, the initialization command procedure of the eMMC further comprises, after the initialization command procedure of the eMMC is executed, sending a communication parameter setting instruction to configure the communication parameters of the eMMC, sending an update preparation instruction to make the eMMC enter a preparation update state, and downloading the update firmware into the eMMC in the preparation update state. In this way, after the initialization command procedure is executed each time, the configuration of the communication parameters is performed first, and the configuration of the communication parameters is completed before the data interaction step between the Android system and the eMMC, so as to ensure that the data sender and the data receiver can interact based on the same communication parameters, and avoid data loss in the transmission process. This corresponds to S323.

[0138] The communication parameters include block_len, HS_timing, and bus_width. The block_len can be set by Cmd16 in the eMMC protocol to set the block length (in bytes) for all block commands (read and write), and the minimum block read / write unit is set to 512 bytes by default. The HS_timing is set by Cmd6 to set the frequency of communication between the host and the eMMC, and the HS mode can be set to speed up the communication efficiency with the eMMC. The Bus_width is set by Cmd6 to set the bus width of communication between the host and the eMMC, for example, the bus width can be set to 1 bit, 4 bits, or 8 bits. The update preparation instruction is Cmd60, and the eMMC enters the preparation update state (emmc fw update flow) after receiving the update preparation instruction.

[0139] In an alternative embodiment, the initialization command procedure can be completed by executing cmd0→cmd1→cmd2→cmd3→cmd9→cmd7 according to the eMMC protocol standard.

[0140] In an alternative embodiment, the power supply of the eMMC includes a core power supply and an input / output power supply, wherein the core power supply supplies power to the core module of the eMMC, and the core module includes a storage unit, a control logic unit, and an internal voltage regulation unit; and the input / output power supply supplies power to the external interface circuit of the eMMC.

[0141] During the execution of the Android system bootloader, the various cmd commands described above can be issued to the eMMC by the Android system for execution, and the cmd command is a command in the eMMC protocol standard or a custom command configured according to the eMMC protocol standard, so as to be recognized and executed by the eMMC to perform the corresponding process.

[0142] Embodiment Four

[0143] Please refer to Figure 2 The above method for opening a card is applied to an actual scenario, which includes:

[0144] (1) When packing the update firmware bin into the Android system, the card opening capacity level (1-8, representing 8G, 16G, 32G, 64G, 128G, 256G, 512G and 1T different capacity levels) is configured in the uboot (boot loader) source code. It is equivalent to S01 described above.

[0145] (2) The final capacity value required to be written into the eMMC of different capacity levels is calculated by the algorithm. The updated capacity value is written into the update firmware bin again, and the modified update firmware data is recalculated to update the firmware bin data. It is equivalent to S01 described above.

[0146] (3) Control the core power supply VCC of eMMC and the input and output power supply VCCQ reset, send cmd61 to eMMC, make eMMC enter read-only code mode (ROM Code), and then perform cmd0→cmd1→cmd2→cmd3→cmd9→cmd7 initialization process on eMMC. It is equivalent to S321 and S322 described above.

[0147] In the eMMC protocol standard, cmd0: reset the device (i.e. eMMC) to idle state; cmd1: request the device in idle state to send its operating condition register content on the CMD line (Command line, command transmission line) through response; cmd2: request the device to send its CID (identification) on the CMD line; cmd3: allocate a relative address for the device; cmd9: the addressed device sends its device-specific data (CSD) on the CMD line; cmd7: used to switch the state of the device, to switch between standby state and transmission state, or programming state and disconnected state.

[0148] (4) Set the eMMC communication parameters: set block_len by cmd16; set HS_timing, bus_width by cmd6. It is equivalent to S323 described above.

[0149] (5) Send cmd60 to eMMC, make eMMC enter the preparation update state emmc fw update flow, and prepare to send firmware to eMMC. It is equivalent to S324 described above.

[0150] (6) Send cmd25+cmd12, transmit the update firmware bin data to eMMC. It is equivalent to S325 described above.

[0151] (7) Send cmd13 to check the eMMC state, confirm that the update firmware is normally received by eMMC. It is equivalent to S326 described above.

[0152] (8) Control the core power supply VCC and the input and output power supply VCCQ of the eMMC to reset, and then perform the initialization process of cmd0→cmd1→cmd2→cmd3→cmd9→cmd7 on the eMMC. This is equivalent to S326 described above.

[0153] In an alternative embodiment, twice card opening process is included, so after S326, it further includes:

[0154] (9) Set the eMMC communication parameters: set block_len by cmd16, and set HS_timing and bus_width by cmd6.

[0155] (10) Send cmd26 to reprogram the CID content.

[0156] (11) Control the core power supply VCC and the input and output power supply VCCQ of the eMMC to reset, and then perform the initialization process of cmd0→cmd1→cmd2→cmd3→cmd9→cmd7 on the eMMC.

[0157] (12) Brush in the system image of normal boot, and complete the normal boot process of the Android system. This is equivalent to S4 described above.

[0158] Embodiment Five

[0159] Please refer to Figure 6 An electronic device 400 includes a memory 402, a processor 401, and a computer program stored on the memory 402 and executable on the processor 401, and the processor 401 implements each step of the card opening method as described in Embodiment One when executing the computer program.

[0160] The electronic device can achieve the same beneficial effects as the card opening method described above, which will not be repeated here.

[0161] In summary, the application provides a card opening method and electronic equipment, which is realized by modifying the bootloader to complete the card opening operation in the execution stage of the bootloader, without disassembling the disc for card opening. As long as the platform carrying the disc can start to the uboot stage, the card opening of the disc to be opened can be completed, and the disc does not need to be physically disassembled during maintenance. It does not rely on manual operation, and does not need to use external hardware tools, software tools, and card opening image files. The modified uboot can be directly transplanted to different on-board platforms for loading different operating systems, and has strong flexibility. The disc to be opened is re-opened without disassembling the solder. The problem that the card opening must be completed through a special jig and disassembling the solder is solved, the card opening efficiency is improved, and the particles in the disc can be effectively protected from being damaged by high temperature during disassembling the solder. The application is realized in the bootloader stage, so even if the system cannot normally complete the boot process, as long as it can start to the bootloader stage, the card opening and refreshing of the internal firmware data of the disc can be completed. The application does not need to complete the interaction with the disc through the upper application. The application uses the characteristic that the bootloader can communicate with the disc after completing the hardware initialization program and loading the bus function, breaks away from the limitation of accessing the disc after the complete system starts, accesses the disc in the bootloader execution stage to complete the card opening, and provides a card opening process with higher efficiency and more convenient steps.

[0162] In the above-described embodiments provided in the present application, it should be understood that the disclosed methods, devices, computer-readable storage media, and electronic devices can be implemented in other manners. For example, the above-described device embodiments are merely illustrative. For example, the division of the modules is merely logical function division. In actual implementation, another division manner can be used. For example, a plurality of components or modules can be combined or integrated into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed components can be indirect coupling or communication connection through some interfaces, devices, or components or modules, and can be electrical, mechanical, or in other forms.

[0163] The components described as separate components may or may not be physically separate, and the components shown as components may or may not be physical modules, that is, they can be located in one place or distributed on a plurality of network modules. Part or all of the components can be selected according to actual needs to achieve the purpose of the present embodiment.

[0164] In addition, the functional modules in each embodiment of the present application can be integrated into one processing module, or each component can exist physically, or two or more modules can be integrated into one module. The above integrated module can be realized in the form of hardware or in the form of a software functional module.

[0165] The integrated module, if implemented in the form of a software function module and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various program code storage media.

[0166] It should be noted that, for the foregoing method embodiments, in order to facilitate description, they are all described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited to the order of the described actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0167] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0168] The above is only an embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent transformation or direct or indirect application in the related technical field based on the content of the specification and drawings of the present application is also included in the patent protection scope of the present application.

Claims

1. A method for opening a card, characterized in that, include: Obtain the file size of the activation firmware, and increase the partition size of the image configured in the bootloader according to the file size of the activation firmware; Enable bus functionality in the configuration corresponding to the bootloader during program compilation; Disable the bootloader's reference to the kernel layer and delete the bootloader's jump function to the folder corresponding to the kernel layer; Add a device tree driver corresponding to the bus function to the device tree driver corresponding to the bootloader, and add a device tree node for power-on control of the bus function to the hardware configuration information of the bootloader execution stage in the device tree source file, so that the bootloader execution stage can use the bus function. The card activation program is written into the last item of the boot list of the bootloader; when the card activation program is executed, the card activation firmware is burned to obtain card activation data, and the card activation data is sent to the disk to be activated through the bus function to complete the card activation of the disk to be activated. Before writing the card opening program to the last list item of the boot list of the bootloader, the process also includes writing the bus function uninstallation driver and the disk uninstallation driver to the bootloader. When the card to be opened is opened, the bus function is uninstalled according to the bus function uninstallation driver, and the card to be opened is uninstalled according to the card unloading driver.

2. The card opening method according to claim 1, characterized in that, Before obtaining the file size of the activation firmware, the process also includes: If the disk to be opened is eMMC, then calculate the capacity value to be written into the eMMC according to the opening capacity level of the eMMC, and write the capacity value into the opening firmware; Update the verification value of the activation firmware.

3. The card opening method according to claim 1, characterized in that, The compilation of the program that enables bus functionality in the configuration corresponding to the bootloader also includes: If the disk to be opened is a solid-state drive (SSD), then enable the macro definition switch for the SSD in the configuration corresponding to the bootloader, so that the card opening program can complete data interaction with the SSD through macro definitions during the execution phase of the bootloader.

4. The card opening method according to claim 3, characterized in that, The step of sending the card activation data to the disk to be activated via the bus function includes: Obtain the minimum read / write unit of the solid-state drive, align the card activation data with the minimum read / write unit through the bus function, and send the card activation data to the solid-state drive.

5. The card opening method according to claim 4, characterized in that, The step of obtaining the minimum read / write unit of the solid-state drive, aligning the card activation data with the minimum read / write unit through the bus function, and sending the card activation data to the solid-state drive includes: Obtain the first pointer position in the memory cache of the solid-state drive, and determine whether there is an offset between the first pointer position and the minimum read / write unit; If so, the first pointer position is shifted to the starting position of the smallest read / write unit, and the card opening data is sent to the solid-state drive via direct memory access according to the first pointer position; Otherwise, the card activation data is directly transmitted to the solid-state drive via direct memory access based on the first pointer position.

6. The card opening method according to claim 2, characterized in that, The step of sending the card activation data to the disk to be activated via the bus function to complete the card activation of the disk includes: Control the core power supply and input / output power supply of the eMMC to reset, and send cmd61 to the eMMC to make the eMMC enter read-only code mode; The initialization process is completed by sequentially sending cmd0, cmd1, cmd2, cmd3, cmd9, and cmd7 to the eMMC. The communication parameters of the eMMC can be set via cmd16; The eMMC is put into an update-ready state via cmd60; The card activation data is sent to the eMMC via cmd25 and cmd12; The system confirms via cmd13 whether the card activation data is received normally by the eMMC. If so, it controls the core power supply and input / output power supply of the eMMC to reset, and sends cmd0, cmd1, cmd2, cmd3, cmd9 and cmd7 to the eMMC in sequence to complete the initialization process.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the card opening method as described in any one of claims 1-6.

Images