mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-26 06:30:39 +00:00
c4db335c2e
Since the Blackfin ABI favors higher scratch registers by default, use the last scratch register (P3) for global data rather than the first (P5). This allows the compiler's register allocator to use higher number scratch P registers, which in turn better matches the Blackfin instruction set, which reduces the size of U-Boot by more than 1024 bytes... Signed-off-by: Robin Getz <robin.getz@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
98 lines
3.6 KiB
Text
98 lines
3.6 KiB
Text
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, MIPS and Blackfin architectures
|
|
use a dedicated register to hold the pointer to the 'global_data'
|
|
structure: r2 on PowerPC, r8 on ARM, k0 on MIPS, and P3 on Blackfin.
|
|
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
|
|
Blackfin 0x00001000 0x00001000
|
|
|
|
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.
|