A target board booting Linux proceeds through several steps after reset to get to a system prompt. The initial steps, such as ROM startup code and register configuration, are microprocessor hardware dependent. The kernel itself contains microprocessor architecture dependent initialization code that is executed first. This initialization code configures the microprocessor registers for protected-mode operation and then invokes the architecture-independent kernel starting point called start_kernel. From this point on, the kernel boot process is identical for all architectures. The Linux boot process involves the following steps:
The Project Trailblazer engineers learned from the board manufacturers' documentation that steps 1, 2 and 3 are fairly easy to understand, configure, and execute. Step 4 is dependent on kernel compilation configuration. Step 5 presents a wide range of options, including mounting a local disk drive, mounting a network drive, and using a RAM disk. Step 7 requires proper compilation of glibc and other libraries.
The engineers read about replacing the init program with bash directly in step 6. They opted to use init for two reasons. First, init can handle initialization of networking and system services via scripts. Second, in step 9 the engineers will use init to call bash directly instead of using the login process. init can respawn processes that terminate. This means that if bash terminates, init will re-execute it. Use of init fulfills PBR-2. Having bash execute directly instead of login allows console operations without security. The engineers intend to add the login process prior to placing the target board in field operations.
Having init call bash directly instead of login saves time because you don't have to log in during development. In a secure lab, convenience outweighs security. When you deploy designs, you should modify /etc/inittab so that init calls login, to provide the first level of authentication.