| Design Notes on Exporting U-Boot Functions to Standalone Applications: |
| ====================================================================== |
| |
| 1. The functions are exported by U-Boot via a jump table. The jump |
| table is allocated and initialized in the jumptable_init() routine |
| (common/exports.c). Other routines may also modify the jump table, |
| however. The jump table can be accessed as the 'jt' field of the |
| 'global_data' structure. The slot numbers for the jump table are |
| defined in the <include/exports.h> header. E.g., to substitute the |
| malloc() and free() functions that will be available to standalone |
| applications, one should do the following: |
| |
| DECLARE_GLOBAL_DATA_PTR; |
| |
| gd->jt[XF_malloc] = my_malloc; |
| gd->jt[XF_free] = my_free; |
| |
| Note that the pointers to the functions all have 'void *' type and |
| thus the compiler cannot perform type checks on these assignments. |
| |
| 2. The pointer to the jump table is passed to the application in a |
| machine-dependent way. PowerPC, ARM and MIPS architectures use a |
| dedicated register to hold the pointer to the 'global_data' |
| structure: r2 on PowerPC, r8 on ARM and k0 on MIPS. The x86 |
| architecture does not use such a register; instead, the pointer to |
| the 'global_data' structure is passed as 'argv[-1]' pointer. |
| |
| The application can access the 'global_data' structure in the same |
| way as U-Boot does: |
| |
| DECLARE_GLOBAL_DATA_PTR; |
| |
| printf("U-Boot relocation offset: %x\n", gd->reloc_off); |
| |
| 3. The application should call the app_startup() function before any |
| call to the exported functions. Also, implementor of the |
| application may want to check the version of the ABI provided by |
| U-Boot. To facilitate this, a get_version() function is exported |
| that returns the ABI version of the running U-Boot. I.e., a |
| typical application startup may look like this: |
| |
| int my_app (int argc, char *argv[]) |
| { |
| app_startup (argv); |
| if (get_version () != XF_VERSION) |
| return 1; |
| } |
| |
| 4. The default load and start addresses of the applications are as |
| follows: |
| |
| Load address Start address |
| x86 0x00040000 0x00040000 |
| PowerPC 0x00040000 0x00040004 |
| ARM 0x0c100000 0x0c100000 |
| MIPS 0x80200000 0x80200000 |
| |
| For example, the "hello world" application may be loaded and |
| executed on a PowerPC board with the following commands: |
| |
| => tftp 0x40000 hello_world.bin |
| => go 0x40004 |
| |
| 5. To export some additional function foobar(), the following steps |
| should be undertaken: |
| |
| - Append the following line at the end of the include/_exports.h |
| file: |
| |
| EXPORT_FUNC(foobar) |
| |
| - Add the prototype for this function to the include/exports.h |
| file: |
| |
| void foobar(void); |
| |
| - Add the initialization of the jump table slot wherever |
| appropriate (most likely, to the jumptable_init() function): |
| |
| gd->jt[XF_foobar] = foobar; |
| |
| - Increase the XF_VERSION value by one in the include/exports.h |
| file |
| |
| 6. The code for exporting the U-Boot functions to applications is |
| mostly machine-independent. The only places written in assembly |
| language are stub functions that perform the jump through the jump |
| table. That said, to port this code to a new architecture, the |
| only thing to be provided is the code in the examples/stubs.c |
| file. If this architecture, however, uses some uncommon method of |
| passing the 'global_data' pointer (like x86 does), one should add |
| the respective code to the app_startup() function in that file. |
| |
| Note that these functions may only use call-clobbered registers; |
| those registers that are used to pass the function's arguments, |
| the stack contents and the return address should be left intact. |