-1. Add a field to the global_data structure, the pointer to a jump
- table.
-
-2. Jump table itself is allocated and filled in the same way as the
- syscall table is (allocated with malloc() after the code has been
- relocated to RAM); a special function, fixed to the table element
- number 0, will be added which returns the ABI version so
- applications can check for compatibility issues.
-
-3. It is application's responsibility to check the ABI version and
- act accordingly.
-
-4. Pointer to the global_data is passed to the application in the
- dedicated register that is used in the U-Boot to hold this
- pointer. This assumes that the application is built with the same
- register- allocation flags as the U-Boot itself. (Actually, this
- is a requirement even now, as the 'go' command does not perform
- any actions to protect this register against being clobbered by
- the application).
-
- This approach won't work on the x86 architecture. See below.
-
-5. Application now calls standard library functions like printf()
- instead of specially prefixed names like mon_printf() as it did
- before. Present implementation of these functions (using the
- system calls mechanism) will be replaced with jump stubs.
-
-6. To export additional functions, the following steps will have to be
- taken:
-
- - Add the xxx() U-Boot function to the EXPORT_FUNC list
- - Add initialization of the appropriate slot in the jump table
-
-7. To port to a new architecture, the appropriate stub code should be
- provided. No other machine-dependent code is used. Once the stub
- template is available, no additional coding is needed when
- exporting new U-Boot functions. A pre-processor macro will be used
- to automatically instantiate the stub definition for each exported
- function.
-
-Note the following:
-
-- This approach uses a jump table with fixed slot allocation. That
- said, to retain the ABI compatibility, no table reordering,
- inserting new functions in the middle of the list or deleting
- functions from the list is allowed. Any such action will break the
- ABI compatibility.
-
-- The x86 architecture does not use a dedicated register to store the
- pointer to the global_data structure. There are the following
- approaches available:
+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 struct members 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->malloc = my_malloc;
+ gd->jt->free = my_free;
+
+ Note that the pointers to the functions are real function pointers
+ so the compiler can 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, MIPS, Blackfin and Nios II
+ architectures use a dedicated register to hold the pointer to the
+ 'global_data' structure: r2 on PowerPC, r9 on ARM, k0 on MIPS,
+ P3 on Blackfin and gp on Nios II. 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 * const 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
+ Blackfin 0x00001000 0x00001000
+ NDS32 0x00300000 0x00300000
+ Nios II 0x02000000 0x02000000
+ RISC-V 0x00600000 0x00600000
+
+ 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