Dm365 video processing process/dm368 NAND Flash startup secrets

The video processing of dm365 involves three related processors: video capture chip, ARM processor, and video image coprocessor (vicp). The entire processing process is coordinated by the ARM core. Video Processing mainly involves three processing processes: video collection, video encoding, and processing of encoded videos. To improve performance, a processing thread is usually provided for each processing process.
Video collection
Tvp5146 converts the collected video data into a digital signal, sends the data to the bt656 interface of dm365, and then obtains the required resolution through resize, the data is then written to the specified memory, which is allocated by the cmem module. The cmem module is used to allocate continuous storage space. Continuous storage space can improve data read and write efficiency.
Video Encoding
Vicp reads video data from a specified bucket, encodes the data into a specified video/image format, and then writes the encoded data to the specified bucket, these buckets are usually allocated by the cmem module.
Encoding data processing
Arm obtains the encoded video data from the specified memory space. The encoded data can be stored locally or remotely, or sent to the network using the RTP protocol.
The entire process is coordinated by the ARM core. In order to improve efficiency, a large number of DMA operations and the continuous storage space allocated by the cmem module are used.

 

Texas Instrument Onsite technical support engineer Meng Haiyan

Summary:

This article introduces the principle of starting dm368 NAND Flash, and introduces how the software works with hardware to start the dm368 ipnc.

Keywords: NAND Flash startup, RBL, UBL

How does one enable and implement the application function after the chip is powered on? This is a problem that many engineers usually ask when they see that the processor is running. Next we will take the multimedia processing chip tms320dm368 of Texas Instrument as an example to introduce its NAND Flash startup principle and implementation.

I. NAND Flash startup Principle

TI's multimedia processing chip, tms320dm368, can implement P30 h264 encoding, which has been widely used in Network Camera applications. Dm368 supports the nor flash, NAND Flash, UART, and SD card startup modes. For NAND boot, dm365 supports the following features:

1. All firmware files cannot be downloaded and started at one time. Instead, you need to copy the second-level startup code (UBL) from NAND flash to the arm's memory (AIM) to transfer the control to the User-Defined UBL.

2. Supports NAND with a maximum page size of 4 kb.

3. Supports error detection of special numeric signs. A maximum of 24 attempts are allowed when UBL is loaded. For example, if no special numeric marker is found in the 1st blocks of NAND, the next block is used for further searching until 24th blocks are found.

4. Support 30 kb UBL (dm365 has 32 KB of memory, of which 2 kb is used as the RBL stack, and the remaining space can be placed in UBL)

5. You can choose whether to support DMA and I-Cache when RBL is executed (for example, when UBL is loaded)

6. Use and require 4-bit hardware ECC (supporting NAND Flash with ECC digits smaller than or equal to 4 for every 512 bytes ).

7. Support for NAND flash that requires a chip selection signal with a low reading time of TR.

Some users use the NAND Flash startup mode to save costs in the application of network cameras. Figure 1 shows a brief flowchart from power-on to Linux Startup. First, RBL (ROM Boot Loader) reads UBL (user boot loader) from NAND and copies it to arm's memory. UBL runs in arm memory and initializes the system, for example, initializing DDR. UBL then reads the U-boot content from the NAND Flash and copies it to the DDR for running. The U-boot running in the DDR reads the Linux kernel code from the NAND Flash, copies the code to the DDR, and then starts the kernel. In this way, the dm365 system starts from power-on to the Linux kernel, and then runs the corresponding application.

Figure 1 NAND Flash Startup Process

Next we will introduce step by step how to implement it from power-on to Linux Startup.

First, we need to mention the concept of RBL, that is, Rom Boot Loader (ROM Boot Code ). There is a rom area on the dm368 chip (from 0x00008000 to 0x0000 bfff). This area is where the RBL code is stored. The Code on the Rom is written before the chip leaves the factory, and users cannot modify it. In dm368, apart from aemif (nor flash) Startup, RBL must be run in other startup modes.

Whether it is power-on reset, hot reset, or watchdog reset, when the reset signal is low to high, the dm368 chip will detect the btsel [] pin (start selection pin ). As long as it detects that the level is not 001, It is not aemif (nor flash) to start, the arm program will start from the arm Rom address 0x00008000 address.

RBL will first read the btsel information in the bootcfg register. if it finds that the status of the btsel is 000, it will know that the configuration is nand flash Boot, And the NAND start mode starts to run. Note: To ensure normal operation of the NAND startup, ensure that the deepsleepz/gio0 pin is increased during the reset. After confirming that the disk is started with nand, RBL initializes the memory of up to 2 kb as a stack and closes the disk, thus interrupting the disk. Then RBL reads the nand id information, and then lists the NAND IDs in the RBL code to learn more detailed information about the NAND Flash, such as the page size, configure EMIF. You can find the ID of the NAND that can be started in dm368 in reference 1 (arm subsystem User Manual. When selecting hardware, be sure to select the NAND chip supported in the nand id list.

Next, RBL searches for the UBL descriptor on the 1st pages of The 0th block in NAND Flash. If you do not find a valid UBL special numeric flag, RBL continues to search for the descriptor on The 0th page of the next block, up to 24th blocks. RBL will search for descriptors in multiple Blocks Based on the features of NAND Flash, which are easy to use and Bad blocks. 24 blocks should be enough to avoid the impact of Bad blocks in NAND Flash.

For example, if RBL finds a valid UBL descriptor in a block, the block number is written to the last 32-bit (0x7ffc ~ 0x8000) is used for debugging, and the specific content of the UBL descriptor will be read and processed. The UBL descriptor tells RBL about the information required to download and grant control to UBL, as shown in table 1.

0th page address	32-bit	Description
0	0xa1ac edxx	Special Digit Sign
4	UBL entry address	User Startup code entry address (absolute address)
8	Page number used by UBL	Page number (the size of diamond enabled by the user)
12	Block number starting with UBL	Start to store the block number of the User Startup code)
16	Page number starting with UBL	Number of pages that start to store User Startup code
20	PLL settings-m	PLL setting-rate (valid only when a special digital standard is used to indicate PLL enabling)
24	PLL settings-n	PLL setting-percentage (effective only when a special digital standard represents PLL enabling
28	Quick EMIF settings	Quick EMIF settings (only valid when the quick EMIF is started according to the special numeric Standard)

Table 1 nand ubl Descriptor

Once the startup settings are configured, RBL moves UBL from the address 0x0020 to the arm memory. During the process of reading UBL from NAND, RBL uses the 4-bit hardware ECC to check and correct the data on NAND Flash. If the read fails for other reasons, the copy will stop immediately, and RBL will continue to look for a special digit mark in the next block.

Precautions for UBL descriptors:

1. The entry address must be between 0x0020 and 0x781c.

2. The page for storing UBL must be continuous and can be distributed in multiple blocks. The total size must be smaller than 30kb.

3. the starting block number of UBL can be the same as the block number for storing UBL descriptors.

4. If the starting block number of UBL is the same as that of the UBL descriptor, the starting page number of UBL must not be the same as that of the UBL descriptor.

However, after RBL successfully copies all UBL files to the arm Memory Based on the UBL size information provided in the UBL descriptor, RBL jumps to the UBL start address, so that the control of the chip is handed over to UBL, UBL started to run in arm memory.

Maybe you will ask, since RBL can copy the content on NAND flash to the arm memory for running, why don't we directly copy U-boot to the memory for running? The reason is that the arm memory is too small. Generally, U-boot is larger than kb, while dm365 can be used to start up with only 30 kb of memory. Maybe you have to ask again, why don't you copy U-boot directly to DDR and run it? DDR has enough space? This is because after the chip is powered on, it cannot know the DDR information that the user receives on the DDR2 interface of dm365, and RBL Cannot initialize the DDR, which is unavailable during the RBL operation stage. This is why initializing DDR in UBL is an important task.

When the NAND startup fails, RBL will continue to try the MMC/SD startup mode. If your system starts with nand, but the content on the NAND is damaged, if your board has an SD card interface, you can change the startup mode, then you can use the SD card to first start the system and then re-burn the content on the NAND Flash. This can be used as a remedy on the customer side after the product expires.

2. Implementation of Software integration with NAND Flash

Now we know how dm368 NAND flash starts. Let's take a look at how the software is started according to and in line with hardware requirements. In the dm368 ipnc software package, there is a tool Directory, which contains the pre-compiled executable files of CCS that burn and write nand, UBL binary files and related source code.

When introducing the NAND Flash startup principle, we mentioned that RBL needs to search for special numbers on NAND Flash. This special digital mark was written to flash by the CCS project that burned the NAND. In flash_utils_dm36x_1.0.0 \ flash_utils_dm36x \ dm36x \ CCS \ nandwriter \ SRC \ nandwriter. C, the local_writeheaderanddata () function is used to write the descriptor.

// Setup header to be written

Headerptr = (uint32 *) gnandtx;

Headerptr [0] = nandboot-> magicnum; // magic number

Headerptr [1] = nandboot-> entrypoint; // entry point

Headerptr [2] = nandboot-> numpage; // Number of pages

# If defined (ipnc_dm365) | defined (ipnc_dm368)

Headerptr [3] = blocknum + 3; // starting block number

Headerptr [4] = 0; // starting page number-always start data in page 1 (this header goes in page 0)

Compared with table 1, you can see that headerptr [3] is used to store the starting block number of UBL code. Here + 3 means that UBL is stored in the third block after the block number put by the UBL descriptor. Headerptr [4] = 0 indicates that the data is stored on the 0th page. Of course, this value can be modified by the user. As long as you burn the UBL code, the position is the same as the starting block/page number in the descriptor.

In the ipnc code, the UBL descriptor is written from the 1st block of NAND Flash. If the block is good, it is placed on the 1st page of The 0th block. If 1st blocks are bad, the UBL descriptor will be written to the 0th page of the next block. In the ipnc code, the possible block numbers of the UBL descriptor are not counted from 1 to 24 blocks (this is the range of RBL search). It only ranges from 1st blocks to 3rd blocks. If the UBL descriptor is placed in 1st blocks, if the 4th blocks are good, the UBL code will start from the 4th page of The 0th blocks.

# Elif defined (ipnc_dm368)

// Defines which NAND blocks the RBL will search in for a UBL Image

# Define device_nand_rbl_search_start_block (1)

# Define device_nand_rbl_search_end_block (3)

In nandwriter. C, you can also see that the UBL entry address is fixed to 0x100.

Gnandboot. entrypoint = 0x0100; // This fixed entry point will work with the ubls

To understand why it is 0x100, you must check the UBL source code. In the UBL. CMD file of UBL source code, you can see the following definition. Place the entry address in the boot directory, and the boot running address is 0x100.

-E boot // specify the entry address as boot.

...

Memory

{

...

Ubl_ I _text (RX): Origin = 0x00000100 length = 0x00004300

...

Ubl_f_text (R): Origin = 0x020000e0 length = 0x00004300

...

}

Sections

{

...

. Text: load = ubl_f_text, run = ubl_ I _text, load_start (flashtextstart), load_size (flashtextsize)

{

* (. BOOT)

. = Align (4 );

* (. Text)

. = Align (4 );

}

....

}

In the UBL source code boot. C, the Initial Startup code is forcibly placed in the boot section.

# If defined (_ tms470 __)

...

# Pragma code_section (BOOT, ". Boot ");

# Endif

Void boot (void)

{

...

}

In this way, the UBL program runs from the address 0 x from the CMD configuration and code specified code segment.

UBL starts U-boot and uses RBL to start UBL. The same local_writeheaderanddata () function is used to burn the descriptor. In nandwriter. C, we call the U-boot code application code (APP ).

// Defines which NAND blocks are valid for writing the APP data

# Define device_nand_ubl_search_start_block (8)

# Define device_nand_ubl_search_end_block (10)

Below is the initial serial port printing after ipnc is started.

Valid magicnum, 0xa1aced66, found in Block 0x00000008.

Done

Jumping to entry point at 0x81080000.

We can see that UBL indicates that the U-boot descriptor is found in the 8th blocks. The definitions of device_nand_ubl_search_start_block are consistent.

Ipnc Code supports updating UBL or U-boot itself in U-boot. The following are the commands for burning UBL and U-boot in U-boot.

Write UBL:

Nand write 0x80700000 0x080000 0x08000

Run U-boot:

Nand write 0x80700000 0x160000 0x28000

To learn why the NAND Flash burning address is 0x80000 and 0x160000, you still need to understand the burning process in nandwriter. C. We can know from the previous content that nandwriter. C has written UBL starting from 1 + 3 = 4, while u-boot has been written from 8 + 3 = 11. The NAND Flash used on ipnc is a 2 k page, each block is kb. Therefore, the UBL burning address is 80000 kbx4 = 0x160000, while the burning U-boot address is kx11 = 0 x.

So if there is no bad NAND Flash block, nandwriter. C will burn the UBL descriptor on 1st pieces of 0th pages, burn the UBL code on 4th pieces of 0th pages, and run the U-boot (APP) the descriptor is written on 8th pieces of 0th pages, and the U-boot code is written on 11th pieces of 0th pages. In this way, after the chip is powered on and confirmed to be started by NAND Flash, RBL will find the corresponding UBL descriptor during execution and run the UBL-Loaded Arm memory. UBL finds the U-boot Descriptor and loads U-boot to the DDR for running. At last, U-boot loads uimage and starts Linux, and completes the entire process from power-on to Linux Startup.

Iii. Conclusion

Each chip generally has multiple boot methods, and each chip has different boot methods, but there is something similar. The above introduction can also serve as a reference for learning other startup methods of other chips.

Finally, I would like to thank Li Bin for his help in this article!

References

1. tms320dm36x Digital Media System-on-chip (dmsoc) arm subsystem User's Guide literature number: sprufg5a

2. tms320dm368 datasheet literature number: sprs668c