A method for starting an embedded system adapting to various types of flash chips

Abstract

The invention discloses an embedded system booting method adaptive to various Flash chip types. Steps of adaptation to various Flash chip types are executed in the loading program Bootloader of an embedded system. The method comprises the steps that a standard command for reading chip ID information is sent to a Flash chip used in the embedded system; according to a manufacturer ID and an equipment ID returned by the Flash chip, a pre-configured Flash chip parameter configuration table is queried to obtain configuration information corresponding to the Flash chip; the loading program Bootloader continues to access and / or operate a program and / or data in the Flash chip according to the configuration information. The universality of Uboot is improved, unnecessary repeated development and maintenance work is reduced, and the code efficiency is improved.

Description

technical field [0001] The invention relates to a startup method of an embedded system, in particular to a Uboot startup method based on NAND Flash self-adaptation, capable of self-adaptation to different NAND Flash chip types, and the invention is suitable for communication and computer fields. Background technique [0002] In embedded development, Uboot (that is, Bootloader) is an indispensable and important link to guide the Linux system. Similar to the BIOS setting of Windows, this process is very important for the power-on initialization and boot work of the system; at the same time, this process is also It can complete some customized work, such as automatically verifying the integrity of the Flash to determine whether the boot partition is damaged; providing password protection to protect Uboot from being modified by misuse; providing device lighting operations to remind users that they are currently in the state of the boot environment, etc. . [0003] However, ther...

AI Technical Summary

Problems solved by technology

[0003] However, there are some problems in the use of the existing boot methods. For example, Uboot itself is also a program, which also needs to be stored on non-volatile media (such as SD card, NAND Flash, QSPI Flash, etc.). The important thing is to read the Flash content, load the Linux system, read the register space of the device, set the initial state of the device, etc.), the Uboot program needs to determine what type of hardware Flash chip to read and write, including the block size of Flash (blocksize), page size (page size), spare area (Spare Area) and other parameters, so the corresponding Uboot code may need to read and write a lot of different Flash chip content, especially in the case of diverse project requirements, such as Micron4GB Flash, Micron When using 1GB Flash, Spansion 1GB, Toshiba 1GB Flash and other Flash chips with different capacities from different manufacturers, because the read and write parameters of these Flash chips are different, the program developer needs to manually modify the Uboot code and statically configure the corresponding Flash chip parameters In the Uboot source code, compile the Uboot source code, and then burn it into the non-volatile medium, so that Uboot can know what type of Flash chip it needs to read and write when it starts.

[0004] In the above process, the business logic process of the Uboot code itself has not been modified, such as starting, booting the system and other key steps, but just because the read and write parameters of the Flash chip cannot be recognized, it is necessary to manually modify the code, compile, burn, and follow-up The testing process, this process is quite cumbersome, and the system needs to be upgraded, and multiple sets of Uboot codes need to be maintained at the same time, and the difference between each source code is very small

Images