summaryrefslogtreecommitdiffstats
path: root/doc/README.standalone
blob: 39988317ee5971abf7240bf01e641e30aeb71aa3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
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.
OpenPOWER on IntegriCloud