upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
u-boot/doc/README.standalone

3.6 KiB

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: r29 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.