Rex Startup Process

1. Brief Process Analysis of startup
Qualcomm platform software supports two startup modes: one is nor flash startup mode, and the other is
Is the NAND Flash startup mode. The Flash startup method is equivalent to finding an entry point for the hardware to start code execution,
Nor
This method is relatively simple, and amoi does not use this method, so this method is not analyzed in detail.
Another method is the NAND Flash startup mode, which is similar to the PC Startup Mode and also used by amoi.
Boot Mode. The following describes the boot process in detail.
After you press the power-on key, a clock interruption will occur, notifying the Boot Load hardware of the main chip of AMSS
Copy the boot code in the first block (8 K) on the NAND flash to the kernel memory (RAM
The memory should be the memory of the CPU,
It is different from the SDRAM mentioned later,
It can be used as the CPU cache)
And run the boot code. The main task of boot is to complete the hardware initialization of the entire system.
Work (similar to the hardware self-check work completed by the BIOS on the PC. As for the detailed working mechanism of boot
Detailed description)
. In the work completed by boot, the most important thing is that the entire mobile phone software code (AMSS soft
Package) is copied to the SDRAM, and the control is finally handed over to the AMSS software. To put it bluntly, the boot execution is complete.
The execution point of the Code will jump from boot to the main () function of the entry point of the AMSS software. (This function is available in mobile. C.
)
.
After the code runs to main (), the initialization of the Operating System (Rex) will be completed in this function. In fact
The current method is to call
Rex_init (). Rex_init () Does the following:
1. Complete the necessary data structures of the Operating System (timer linked list, task linked list, etc)
;
2. Next, it creates three tasks: rex_idle_task, rex_dpc_task, and tmc_task.
There is nothing to explain about the idle task. At present, this task is empty and nothing is done. dpc_task does not know what to do.
You don't need to worry about it. Both of the preceding tasks belong to the operating system level and are maintained by the operating system.
Mobile phone software has little to do. Which one has a big relationship with mobile phone software? The answer is: tmc_task. You can take this as an exercise.
As the system entry (main) task, you can also regard it as the entry task of the entire mobile phone software. That is, all
The tmc_task is used to create and maintain its tasks.
So far, the entire AMSS software has not been run, but it just ran into tmc_task. In tmc_task
Tmc_init () is called to initialize the entire AMSS package. The most important task is
Call tmc_define_tasks () to create all the tasks required by the AMSS package. For example, slee_task,
Dog_task, cm_task, wms_task, and ui_task. These tasks generally do not need to be directly handed in with the Al layer software.
But remember that the most fundamental implementation of all functions on mobile phones is that these service components (service tasks)
Completed. When you track a specific function module in the future, such as the call module, You can go deeper if necessary.
Study its implementation.
All right, so far, all the core AMSS software has been running (the function module of the mobile phone is
It is a task at the OS level)
. However, we still cannot see brew and aee. Haha, various
Bit. At this level, I would like to say a few more words. The earliest Qualcomm platform, such as the 5xxx Series
Column, there is no brew at all. At that time, the application layer software development directly calls the underlying
The API provided by the service task to complete the corresponding work. From this perspective, it is obvious that the development at that time is
Relatively depressing and difficult. However, after 65xx, the Qualcomm platform introduced brew
There is no need to develop mobile phones at such a bottom layer (Service API). They can be fully implemented based on brew.
All functions of a mobile phone (the reference code given by Qualcomm is the full BREW Platform)
.
How does brew's runtime environment aee run? The key lies in ui_task (), because ui_task and our mobile phone
The development relationship is very close, and its position is also very important. Therefore, I will conduct an in-depth research and
Analysis. So far, you only need to know That ui_task has loaded aee and it has started to a middle layer.
That is, all messages of the underlying AMSS service components are forwarded to aee through ui_task, and finally to the specific
In the app (applet) Execution Code (handleevent ())
.
Note:
1. During the above boot process, all the functions of the entire system are required after each press on key.
But some software modules are running at the underlying layer. Is
The reason is simple because our platform software is based on
Started in NAND flash,
All codes must be copied to the SDRAM to run,
After power-off,
SDRAM
So there is no doubt that the above process must be executed every time the system is started;
2. The shutdown process is relatively simple. After the system detects that the shutdown is interrupted, it will call tmc_powerdown_handler
() To complete the shutdown operation, it will stop all AMSS tasks, and finally call rex_exit () to exit Rex,
To complete the entire shutdown operation.
3. Obviously, if necessary, each task must save the information it wants to save to flash
So that the information can be obtained at the next boot;
Brief diagram of the boot process
Note:
1. TMC is the most closely related task between the operating system and AMSS software, but it must be repaired by the OEM.
There should be few changes;
2. At the operating system level, ui_task is a task that OEMs need to focus on. It is a task that connects to the underlying task.
An intermediate layer of the Upper-layer Al may need to be added to the OEM's operation process;
3. coreapp is an entry applet for the Al layer at the brew layer, which manages the entire upper layer of the Al layer software.
Function. This app must be customized based on product requirements;
4. aee is the operating environment of the Upper-layer app,
Currently, Qualcomm has not published its source code,
But its operating mechanism,
Amoi needs to be well studied. I will go to another article titled in-depth analysis and research on the operating mechanism of the Qualcomm platform aee.
To explore its operation mechanism and scheduling mechanism. If you are interested, refer to this article;

Ii. In-depth analysis of Boot Code

Most of the boot code is written in assembly language, and a small part may need to be modified by the OEM. Therefore, C language is used.
Let's talk about it. In addition, the boot code is in the driver range, so you can find the corresponding
Code. The boot code is very modularized. The entire boot entry point is in boot_function_table.s,
In this assembly code, the tasks to be completed by boot are encapsulated into different functions, which are completed by different functions.
Next, I will analyze the work completed by these functions in depth, as described below.
A) mmu_enable_instruction_cache;
This is only required when the NAND startup mode is enabled. Enable the arm command cache.
B) boot_hw_ctrl_init
This function initializes the controllers of the two bus (ebi1 and ebi2 ).
You can know which devices are connected to the two bus, and you can also find these devices. However
The initialization is not here.
[Note]
This function is very important. If OEMs need to add new devices to the system (mounted on two buses)
, You need to customize
This module is mainly used for memory at present. In addition, as described above, this function is written in C for the main purpose
It is to facilitate OEM customization. Memory device modification, you can find the corresponding data structure in this module, relative
It is relatively simple.
C) boot_hw_tlmm_init
1. Initialization of crystal clock;
2. interrupt table initialization;
3. gpio initialization;
4. The drivers of MSM, except ebi2;
D) boot_rom_test
This function is very simple, just a very simple Rom check.
Block to check)
.
E) boot_ram_test
Ram self-check, the specific algorithm is actually very simple, that is, read, write memory to determine whether the success.
F) boot_ram_init
1. Copy the phone code from NAND Flash to SDRAM.
A. Image _ bb_ram _ base: Core code;
B. Image _ app_ram _ base: app code;
[Note]
The above actions are performed in parts because Qualcomm supports multipart boot load.
2. initialize the image _ zi_region+zi region to 0;
3. initialize the dynamic heap required by the OEM;
4. Data initialization in the code segment is completed directly in the image (completed by the compiler );
G) boot_stack_initialize
Arm stack Initialization is mainly reserved for multipart code loading.
H) boot_cache_mmu_init
Arm MMU Initialization
Note: As of now, the entire boot task is finished, so how does it jump to the main entry of AMSS?
What about the port? The reason is very simple. The arm compiler automatically creates a _ rt_entry () when linking, and the function is complete.
The initial implementation of the number of arm library functions, and the last hop to main () and _ rt_entry () will
.
Boot_reset_handler.s. For details, you don't have to worry too much about it. You just need to understand that boot is finished.

After that, the mobile phone software ran to main and then OK.

Iii. In-depth analysis of ui_task
In the general direction, ui_task only completes two tasks, one of which is necessary initialization (this is also our concern ).
Heart, that is, what is done by ui_task?) another thing is the processing of various semaphores. This is also my
Which events are forwarded by ui_task to the upper-layer app. After figuring out the above two points, we will
The work mechanism of ui_task can be clearly studied.
1. ui_init;
During initialization, ui_task mainly completes the following tasks.
A) create a timer for kick watchdog so that watchdog can get kick in time.
The phone is automatically restarted in ui_task,
This is probably because the timer timeout is too short;
B) Registration call callback, mainly related to emergency calls;
C) The main reason for this work is to speed up the operation of the telephone book on the Al-layer software after the startup.
Speed, but this may lead to a slow boot speed. If the boot speed is too slow, you can consider entering the standby interface,
Open a task in the background to complete the task;
D) initialize the sound device;
E) register the WMS callback with the underlying service task wms_task, which is implemented in the iwms component. From this
From the perspective of wms_task and iwms components,
U
However, the Al layer software and iwms
This work will be done by the Al layer software itself. Of course, the registration callback job can also be performed in Al
The reason why the layer is complete is done here, rather than in the Al layer, the main purpose is that this work can be done with the Al layer
Unrelated, that is, the Al layer does not need to care about this, but this is a required step for the implementation of the Short Message function;
F) register the Keyboard Message callback;
Through this callback, all the key messages will be uploaded to this callback function through the underlying hs_task. Then, send a response.
The number will put all the key information in a global variable ui_key_buffer, and then send a letter ui_key_sig
To the ui_task, it knows where it handles and presses the key message.
Detailed descriptions are provided in ui_handlesignals.
G) initialize the LCD. This is not the real initialization of the LCD hardware device, but the LCD needed by some UIS.
Data Structure initialization has little to do with us;
[Note]
Hardware initialization is completed in hs_task. From this perspective, the system can run to ui_task.
It indicates that the drivers of all hardware devices have been loaded successfully.
H) set the boot flag ui_powerup to true;
I) register the IPC semaphore ui_ipc_sig, which can be ignored temporarily;
J) initialize bridle_initswitable. You can skip this step if you do not know the target;
K) initialize the resource file. The main task is to create a symbolic linked list of the resource file in the Rom.
Let the system find these resource files (the resource files are compiled in the code segment. If this is not done, the system will find
Cannot find these resource files );
L) brew runtime environment aee initialization: aee_init, this function does not see the code, you only need to know,
In this step, the entire brew will run. After aee Initialization is complete, it will automatically start an applet,
That is, corestartapp, and corestartapp will start coreapp;
M) So far, the initialization of ui_task is complete;
[Note]
1) from the initialization of the above ui_task, we can see that the ui_task has not completed the basic skills of the mobile phone Al layer software.
Initialization, such as sim card detection and network initialization, should be completed in coreapp.
2) initialization work related to mobile phone functions,
Completed in coreapp,
The working mechanism of this applet,
Detailed descriptions will also be provided later;
2. ui_handlesignals;
Ui_task mainly handles the following events.
A) Dog feeding;
B) task_stop_sig signal. The task is stopped. Currently, this task is empty and has nothing to do;
C) Processing of task_offline_sig. All these tasks belong to operating system events. Currently, we can
No matter;
D) process the Shutdown signal: coreapphandlestopsig (). This is only required to process ui_task before shutdown.
For example, send a message to coreapp to disable itself and then disable ui_task;
TMC is responsible for handling the system's genuine and genuine customs information. When it is found that it needs to shut down the system, it is called
Tmc_powerdown_handler to complete the corresponding work,
In this example, task _ stop_sig is sent to all tasks.
.
For in-depth shutdown processing, we do not need to know it or know it. We only need to know it in ui_task.
Turn off the function.
Shutdown is an in-depth process,
Each app or task only needs to release the resources they have created.
It will be OK. The shutdown guide line is clearly sent after the key is intercepted in coreapp. In fact, it is also
Yes.
E) when the network is offline, send the offline signal to coreapp;
In fact, this signal can be registered on the coreapp, and then the network status can be updated in time.
I wonder if there is such an interface function.
F) process the key message, which mainly completes the following tasks:
I. Turn on the backlight;
Ii. convert special buttons to virtual key values;
Iii. Processing of Button sound;
Iv. Send the key message to the aee execution environment to distribute the key messages;
[Note]
1. The UI is used by default to enable the backlight. In this case, is it feasible if I don't want to have a backlight when I press the button? View
You have to modify the code here;
2. What is the key distribution mechanism of aee? Can it ensure that the app at the top of the display can always get the key?
APP, that is, if an applet uses its own hide, does it still get the key, and other applets do not
You can get it? I am afraid that the focus will be lost like EMP;
G) Processing aee_app_sig semaphores to complete aee scheduling. This task is the most important task for UI completion.
Work, because the upper-layer app needs to schedule regularly. Currently, this scheduling is triggered by aee_app_sig.
The aee_app_sig semaphore is regularly sent by a timer at the operating system level. Now
To learn more, aee_dispatch will be called on a regular basis. For more details about the aee scheduling mechanism, refer to my other
An in-depth analysis and research on the aee operating mechanism;
H) process the aee_sio_sig semaphores. The code is ignored temporarily;
3. Conclusion
Through the above analysis of ui_task, we can see that ui_task is really related to the mobile phone function (that is, it may need
This is mainly used to initialize the resource file and process the key message. For other parts,
Currently, no amoi concern is required. The implementation of real mobile phone functions, such as the display of the boot logo, SIM card check,
Pin verification is completed in coreapp.
4. Others

Iv. In-depth analysis of coreapp

At present, the coreapp in the reference code has done a lot of work and is complex, mainly including the following.
A) system component initialization;
B) display the boot logo;
C) SIM card detection and PIN code verification;
D) update system status information;
I. Battery status;
Ii. network signal;
Iii. network mode;
E) Maintenance and update of iannunciator;
F) call handling. The input box for making a call;
G) Main Menu processing;
H) Handling of various mobile phone settings;
I) Handling of the host key;
At present, the code in coreapp has done too many things. In fact, it can be completely split into different modules to complete,
It can be roughly divided into the following parts.
1. General control module; (coreapp)
The general control module is used to complete various initialization tasks after the mobile phone presses the enable key, and this module is also the entire mobile phone
It is used to complete the overall work of mobile phones, mainly including the following items.
1. system initialization, SIM card detection, and PIN code verification;
2. Display of the boot logo or boot animation;
3. startup of underlying service programs (wmsapp, dialapp, etc );
4. unified management of system configuration information;
Writing configuration information to NV is a very slow task.
NV, which affects the speed. Therefore, you can open a buffer for configuration information in the memory. The upper-layer app operations are actually
This buffer is then written to NV by the core when it is idle.
5. Shutdown;
[Note]
Because coreapp is under the idle applet interface, in order to realize the "one-click back menu" function,
You may need to modify the key processing function in the ui_task to forward all key messages to the core, so that the core
All key events can be obtained. (Currently, ui_task only sends the key event to aee, while aee only sends
Key event is sent to the current active applet ).
2. Idle module;
It mainly draws pictures on the standby interface, which consists of two parts:
1. system information indicator bar;
2. Standby interface (bitmap, animation, clock, calendar, etc );
3. Soft keys
[Note]
Idle is only responsible for interface work,
Is not responsible for obtaining specific system status information,
This task will be completed by other modules
.
3. Polling
The mobile phone status information query module updates and maintains various mobile phone status information. There are mainly the following types:
A. Battery strength;
B. network signal strength;
C. Network Mode (C/G );
D. plmn network name;
E. Short Messages, call status, and alarm; (this is done by a dedicated module, not listed in the polling column );
F. Various peripheral information (USB, earphone insertion, etc );
G. Other miscellaneous information;
4. Menu Module
The menu module consists of the implementation of the main menu and the implementation of the sub-menu. Generally
The menu system on the machine should be completed by the menu module in a unified manner,
Instead of manually completing each subroutine.
Menu Module
Generally, you only need to go to the main menu, level-2 menu, and level-3 menu. After the level-3 menu
Apps are maintained separately.
5. Other functional app modules;
Each function module is completed by a dedicated app. In this way, the module is highly independent and easy to be opened separately.
. Communication between modules occurs through app startup and message transmission.

5. Postscript

So far, the entire process of Qualcomm from pressing the activation key to the main course page is clear at a glance. Pair
In terms of amoi, there are not many items that need to be concerned about and customized at present. The biggest headache is the transformation of coreapp,
Of course, this is my post. I will elaborate on it in future articles.
I hope this article will help you understand the operating process of the Qualcomm mobile phone software,
If you have any questions,
Please contact me directly. Thank you for reading this article. Thank you.
Vi. References
A%80-v%2-%e_boot_block_downloader%
B000080-v50000-1_k_qct_ext_api_rg1 _
C) Driver/boot directory source code
D) Service/TMC directory source code
E) APP/Core directory source code