Embedded Linux Primer: A Practical, Real-World Approach

[107] You saw that they were initialized just before the machine language call to machine_init. As you can see from Listing 16-5, these register values are passed unmodified to platform_init(). We need to modify this function for our platform. (We have more to say about that in a moment.)

Listing 16-5 also contains some machine-specific calls for power-management functions. If your kernel is configured for PowerPC 6xx support (CONFIG_6xx defined in your .config file), a pointer to a machine-specific power-management function (ppc6xx_idle) is stored in a structure. Similarly, if your kernel is configured for a PowerPC G5 core (CONFIG_POWER4), a pointer to its machine-specific power-management routine is stored in the same structure member. This structure is described in Section 16.3.3, 'Machine-Dependent Calls.'

16.2.3. Static Kernel Command Line

One of the more interesting operations in the machine_init() function reproduced in Listing 16-5 is to store the default kernel command line. This operation is enabled if CONFIG_CMDLINE is enabled in your kernel configuration. On some platforms, the bootloader does not supply the kernel command line. In these cases, the kernel command line can be statically compiled into the kernel. Figure 16-2 illustrates the configuration options for this.

Figure 16-2. Default kernel command line

Enable 'Default bootloader kernel arguments' in the configuration in Figure 16-2 and edit the 'Initial kernel command string' as shown. This results in a set of entries in the .config file, as shown in Listing 16-6.

Listing 16-6. Configuration for Default Kernel Command Line

...
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE='console=ttyS0 root=/dev/ram0 rw'
...

The ellipses in Listing 16-6 indicate that we have taken only a small snippet of the .config file. When these configuration symbols are processed by the kernel build system, they become entries in the .../include/linux/autoconf.h file, as detailed in Listing 16-7.

Listing 16-7. File autoconf.h Entries for Default Kernel Command Line

...
 #define CONFIG_CMDLINE_BOOL 1
 #define CONFIG_CMDLINE 'console=ttyS0 root=/dev/ram0 rw'
...

Now referring back to Listing 16-5, we have the following line:

strlcpy(cmd_line, CONFIG_CMDLINE, sizeof(cmd_line));

You can see that this kernel-based string-copy function copies the string defined by CONFIG_CMDLINE into a global kernel variable called cmd_line. This is important because many functions and device drivers might need to examine the kernel command line early in the boot sequence. The global variable cmd_line is hidden away at the start of the .data section, defined in the assembler file .../arch/ppc/kernel/head.S.

A subtle detail is worth mentioning here. Looking back at Listing 16-4, we see that the machine_init assembly language call is made before the call to MMU_init. That means that any code we are able to run from machine_init is executed in a context with limited support for accessing memory. Many of today's processors that contain an MMU cannot access any memory without some initial mapping via hardware registers in the processor.[108] Typically, a small amount of memory is made available at boot time to accommodate loading and decompressing the kernel and a ramdisk image. Trying to access code or data beyond these early limits will fail. Each architecture and platform might have different early limits for accessing memory. Values on the order of 8 to 16MB are not untypical. We must remember that any code we execute from machine_init, including our platform initialization, takes place in this context. If you encounter data access errors (PowerPC DSI exception[109]) while debugging your new kernel port, you should immediately suspect that you have not properly mapped the memory region your code is trying to access.

16.3. Platform Initialization

Following is a quick review of the code flow during early initialization. Figure 16-3 shows the flow of execution from the bootloader or bootstrap loader to your platform-initialization code.

Figure 16-3. Platform initialization flow of control

The files head.S and setup.c are both found in the .../arch/ppc/kernel directory for the PowerPC architecture. Our custom platform-initialization file will be placed in the .../arch/ppc/platforms directory. In Figure 16-3, it is represented by the file myplat.c. We are now in a position to examine the platform-specific initialization file in detail.

In Listing 16-3, we listed the functions in the lite5200.c platform-initialization file. Every function except platform_init() is declared as static. Therefore, as shown in Figure 16-3, this is the entry point for the platform- initialization file. The rest of the functions in the file are referenced only from within the file itself.

Let's examine the entry function platform_init(). Listing 16-8 reproduces the platform_init() function from the lite5200.c file.

Listing 16-8. Lite5200 platform_init Function

void __init platform_init(unsigned long r3, unsigned long r4, unsigned long r5, unsigned long r6, unsigned long r7) {
/* Generic MPC52xx platform initialization */
/* TODO Create one and move a max of stuff in it. Put this init in the syslib */
 struct bi_record *bootinfo = find_bootinfo();
 if (bootinfo) parse_bootinfo(bootinfo);
 else { /* Load the bd_t board info structure */
  if (r3) memcpy((void*)&__res,(void*)(r3+KERNELBASE), sizeof(bd_t));
#ifdef CONFIG_BLK_DEV_INITRD
  /* Load the initrd */
  if (r4) {
   initrd_start = r4 + KERNELBASE;
   initrd_end = r5 + KERNELBASE;
  }
#endif
 /* Load the command line */
  if (r6) {
   *(char *)(r7+KERNELBASE) = 0;
   strcpy(cmd_line, (char *)(r6+KERNELBASE));