A quick startup burning method for Linux system

Abstract

The invention discloses a quick startup burning method for a Linux system. The method comprises the following steps: importing an IUS package generated by importing an ixl file containing image information into an SD card; powering on, initializing and setting a Linux device; searching for a started peripheral device and searching for a boot program from the started device; searching for an available burning source IUS package from the SD card; reading and executing the IUS package to complete the startup burning of the Linux device; and starting an embedded system through an IROM and burning the image to debug the device.

Description

Technical Field

[0001] The present invention relates to the field of embedded Linux systems, and in particular to a quick startup burning method for Linux systems. Background Art

[0002] With the country's vigorous development of chips in recent years, embedded Linux systems, centered around computer and chip technologies, have become a hot topic of research. Currently, a variety of boot devices are available to boot embedded processors of varying architectures into Linux systems, including Nor Flash, Nand Flash, SD / eMMC, and IROM (internal read-only memory). IROM booting has become a popular method. The IROM contains a section of fixed code that runs before the chip boots the code in flash / eMMC. This section of code is part of the program that automatically runs when the CPU boots up, ultimately loading the image file into SDRAM for execution. In embedded systems, the bootloader performs initial configuration and hardware initialization after device power-up. Due to limited IROM space, it can only perform basic instructions. More functionality generally requires the use of a bootloader stored in external media, such as an SD card.

[0003] After the bootloader initializes the hardware device, it needs to load the kernel image file. The image file can generally be burned into the flash using the USB port, Ethernet port, UART, etc. as a communication interface. However, since this method is more cumbersome, problems such as line instability are often encountered during the burning process. Summary of the Invention

[0004] In view of the above-mentioned shortcomings currently existing, the present invention provides a quick startup burning method for a Linux system, which can start an embedded system through an IROM and burn an image to debug the device.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0006] A quick startup burning method for a Linux system, the method comprising the following steps:

[0007] Import the IUS package generated by importing the ixl file containing the image information into the SD card;

[0008] Power on, initialize and configure the Linux device;

[0009] Search for the bootable peripheral device and search for the boot loader from the bootable device;

[0010] Search the available burning source IUS package from the SD card;

[0011] Read and execute the IUS package to complete the boot burning of the Linux device.

[0012] According to one aspect of the present invention, the IUS package is generated by importing an ixl file containing image information, and each line of ixl is converted into a corresponding descriptor and added to the IUS 480-byte image descriptor list.

[0013] According to one aspect of the present invention, the IUS packet includes: a 32-byte header, a 480-byte file image descriptor list, image data and image MD5.

[0014] According to one aspect of the present invention, the method includes: if an available boot program is found, loading the boot program into the IRAM.

[0015] According to one aspect of the present invention, the method includes: iROM startup starts from the first application instruction, the virtual address of this instruction is 0x0000_0000, the physical address is 0x0400_0000, the iRAM space is used to store variables and stack settings, and the boot program will copy a copy to this space before execution.

[0016] According to one aspect of the present invention, the method includes: if no available burning source is found, but a boot program is found from the startup device, jumping to the IRAM to execute the boot program.

[0017] According to one aspect of the present invention, the method includes: if the boot program is not found in the boot device, the debug shell command line will be entered, and burning can be performed through some specific commands: after the startup starts, if the boot program and program code are not found, QSDK will enter STOP mode and use the biu mode command to enter IROM debugging.

[0018] According to one aspect of the present invention, the method includes: shielding the burning source, adding a flag in the header of the isi file of uboot0, and checking the flag when the IROM retrieves the boot device.

[0019] According to one aspect of the present invention, the isi header of the boot program sets whether to support the hidden function of burning. If it is set in isi, the new uboot will not be loaded each time the iROM is started.

[0020] According to one aspect of the present invention, the method includes: storing the kernel in the SD card, and then loading the kernel into the DDR through the boot program.

[0021] The advantages of the present invention include: using the IUW tool to generate an IUS for a specified image file and importing it into the 16MB address of the SD card; the IUW tool utilizes instructions from the ixl file, where the ISI file verifies the integrity and security of the bootloader through a hash value; the device can start the bootloader from the SD card using the code solidified in the IROM; if the kernel is also stored in the SD card, the kernel can be loaded into the DDR through the bootloader, thereby achieving convenience and security during the device burning and startup process. Using the IUW tool to generate an IUS for a specified image file and importing the ixl file with the ISI file instructions into the IUW tool ensures security and reliability during the burning process. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 This is a schematic diagram of the process of booting the IROM system described in the present invention. DETAILED DESCRIPTION

[0024] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0025] To facilitate the following description, some file formats and tools used in the present invention are first introduced.

[0026] 1. ISI documents

[0027] The InfoTM Secure Image (ISI) file format is defined by InfoTM. This file format has a 512-byte image header and uses a hash value to ensure file integrity. The detailed description is shown in Table 1:

[0028] Table 1.isi file image header composition

[0029]

[0030]

[0031] 2. IUS package file

[0032] Use the IUW tool to generate an IUS package for the specified image file and burn it to the 16MB address of the SD card. After compiling the SDK, a file called burn.ius is generated. This file is generated by the IUW tool. It consists of a 32-byte header, a 480-byte file image descriptor list, image data, and image MD5. Each descriptor describes the iROM execution command, and its composition is shown in Table 2:

[0033] Table 2 IUS package composition

[0034]

[0035] ius_magic: Indicates that this is an IUS packet, and its value is 0x7375692b (+ius).

[0036] hw_versionX: indicates the hardware version number.

[0037] Count: Indicates how many images are contained in this IUS package, with a maximum of 30.

[0038] sw_versionX: indicates the software version number.

[0039] Hcrc: 512 bytes (32 headers + 480 image description list) byte header CRC checksum value.

[0040] 3. IUW Tools

[0041] The IUS package is generated by the IUW (InfoTM Update Wtapper) tool, which is a tool developed by our company to facilitate users to generate IUS packages and burn them. IUW imports the ixl file containing image information. Each line of the ixl file is converted into a corresponding descriptor and added to the IUS 480-byte image descriptor list.

[0042] Use the IUW tool to generate the IUS package. You need to use the burn.ixl file. The first line of code is as follows: i run0x08000200 0x08000000.. / .. / output / images / uboot0.isi

[0043] Only the first command is executed in the iROM; all other commands are executed in the RAM disk burning process after boot. Clearly, the first command executes the image, while the others burn it. After receiving the first execution command, the iROM jumps directly to the load address specified by addr1 to execute uboot0. All other commands are executed after the system boots.

[0044] In this embodiment, when making a flash card, the IUS package is burned to the 16M location on the SD card. During the iROM boot process, it reads the IUS package from the SD card to determine the boot behavior. The IUS package contains many commands and image data, which guide the execution process of the boot device and the location of the burned image.

[0045] like Figure 1 As shown in the figure, the flowchart of IROM starting the system boot is as follows:

[0046] S1. Turn on the hardware power switch, power on the device, initialize the module, and set the clock, serial port, cache, MMC and other devices.

[0047] S2. Check which peripheral devices are started and search for the bootloader from the started device (SD or SPI). If it is flash, the bootloader is stored at address 0. If it is SD / EMMC, it is stored at the 2M position.

[0048] S3. If a usable bootloader is found, it is loaded into IRAM. iROM boot begins with the first application instruction, located at virtual address 0x0000_0000 and physical address 0x0400_0000. iRAM is used to store variables, stack settings, and other information. The bootloader also creates a copy of the bootloader before execution. Generally, a bootloader of up to 64KB is supported. In this case, the bootloader is the file named uboot0.isi.

[0049] S4. Regardless of whether an available bootloader is found, the program source will continue to be searched from the SD or UDC. In the present invention, the UDC is generally shielded in the ISI header and is basically in the SD card.

[0050] S5. If an available burning source is found (usually in the SD card) and is not blocked, read the IUS header from the 16M location of the SD card and execute the first command (that is, the command in the ixl file), that is, run the bootloader in the SD card:

[0051] Use the IUS SD card to load the ISI bootloader image. The IUS package is generated by the IUW tool. IUW imports the ixl file containing the image information. Each line of ixl is converted to a corresponding descriptor and added to the IUS 480-byte image descriptor list. The details of the IUS package format have been described in detail above and will not be repeated here. In this invention, load uboot0.isi into the SPI Norflash using the IUS SD card and add the following command to the beginning of the ixl file:

[0052] i flash 0uboot0.isi

[0053] This descriptor means to burn uboot0.isi to the 0th position of SPI Flash. During the burning process, iROM will automatically perform the erase operation. In this way, iROM will execute the first and second commands in the IUS Header. Since the second command is an execution command, it will jump to the execution directly.

[0054] S6. If no available burning source is found, but the bootloader is found from the boot device in S3, it will jump to IRAM to execute the bootloader.

[0055] If the bootloader is not found in S3, the debug shell command line will be entered, and the program can be burned through some specific commands:

[0056] After the boot process begins, if the bootloader and program code are not found, QSDK will enter STOP mode and use the biu mode command to enter IROM debugging.

[0057] i:yl 8000000 #transmit uboot0 to iRAM through ymodem

[0058] i:vs assign flash #specify the booting device being accessed is SPINorflash

[0059] i:vs erase 00 #erase the content in SPI Norflash

[0060] i:vs write 800000008000 #Program uboot0.i si to SPI Norflash

[0061] Among them, 8000000 is the address of IRAM.

[0062] In actual application, the Program Source Allowed in the flowchart is a design for blocking the burning source in this embodiment, mainly to ensure that uboot0 will not be replaced by other bootloaders and ensure its security. The implementation method is to add a flag in the header of the uboot0 isi file and check the flag when the IROM searches for the boot device. Rely on code implementation:

[0063] *mask=isi_get_flag(base)&BL_PROPERTY_BURN_MASK;

[0064] #define isi_get_flag(x)(((struct isi_hdr*)x)->flag)

[0065] Method to add flag in bootloader: The isi header of bootloader needs to set whether to support burning. This hidden function, if set in isi, will not load new uboot each time iROM is started. In this embodiment, UDC is blocked:

[0066] ISI=$(TOOLDIR)iuw32 genisi-n"uboot0"-t boot-a 0x3c000200-e0x3c000200-f 0x940.

[0067] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A quick startup burning method for Linux system, characterized in that: The method comprises the following steps: Import the IUS package generated by importing the ixl file containing the image information into the SD card; Power on, initialize and configure the Linux device; Search for the bootable peripheral device and search for the boot loader from the bootable device; Search the available burning source IUS package from the SD card; Read the IUS package and execute it to complete the boot burning of the Linux device; The IUS package is generated by importing the ixl file containing the image information, and each line of the ixl file is converted into a corresponding descriptor and added to the IUS 480-byte image descriptor list; The IUS includes: a 32-byte header, a 480-byte file image descriptor list, image data and image MD5; The method includes: shielding the burning source, adding a flag in the header of the isi file of uboot0, and checking the flag when the IROM retrieves the boot device.

2. The quick start burning method of Linux system according to claim 1, wherein The method comprises: if an available boot program is found, loading the boot program into the IRAM.

3. The quick start burning method of Linux system according to claim 2, wherein: The method includes: iROM starts from the first application instruction, the virtual address of this instruction is 0x0000_0000, the physical address is 0x0400_0000, iRAM space is used to store variables and stack settings, and the boot program will copy a copy to this space before execution.

4. The quick start burning method of Linux system according to claim 1, wherein The method includes: if no available burning source is found, but a boot program is found from a startup device, jumping to the IRAM to execute the boot program.

5. The quick start burning method of the Linux system according to claim 4, wherein: The method includes: if the boot program is not found in the boot device, it will enter the debug shell command line to burn through a specific command: after the startup starts, if the boot program and program code are not found, QSDK will enter the STOP mode and use the biu mode command to enter the IROM debugging.

6. The quick start burning method of the Linux system according to claim 1, wherein: The isi header of the boot program sets whether to support the hidden function of burning. If it is set in isi, the new uboot will not be loaded each time the iROM is started.

7. The quick start burning method of the Linux system according to claim 1, wherein: The method includes: storing the kernel in the SD card, and loading the kernel into the DDR through a boot program.

Images