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
|
.. SPDX-License-Identifier: GPL-2.0+
Events
======
U-Boot supports a way for various events to be handled by interested
subsystems. This provide a generic way to handle 'hooks' like setting up the
CPUs after driver model is active, or reading a partition table after a new
block device is probed.
Rather than using weak functions and direct calls across subsystemss, it is
often easier to use an event.
An event consists of a type (e.g. EVT_DM_POST_INIT_F) and some optional data,
in `union event_data`. An event spy can be created to watch for events of a
particular type. When the event is created, it is sent to each spy in turn.
Declaring a spy
---------------
To declare a spy, use something like this::
static int snow_setup_cpus(void *ctx, struct event *event)
{
/* do something */
return 0;
}
EVENT_SPY(EVT_DM_POST_INIT_F, snow_setup_cpus);
Your function is called when EVT_DM_POST_INIT_F is emitted, i.e. after driver
model is inited (in SPL, or in U-Boot proper before and after relocation).
Debugging
---------
To assist with debugging events, enable `CONFIG_EVENT_DEBUG` and
`CONFIG_CMD_EVENT`. The :doc:`../usage/cmd/event` command can then be used to
provide a spy list.
It is also possible to list spy information from the U-Boot executable,, using
the `event_dump.py` script::
$ scripts/event_dump.py /tmp/b/sandbox/u-boot
Event type Id Source location
-------------------- ------------------------------ ------------------------------
EVT_MISC_INIT_F f:sandbox_misc_init_f arch/sandbox/cpu/start.c:125
This shows each event spy in U-Boot, along with the event type, function name
(or ID) and source location.
Note that if `CONFIG_EVENT_DEBUG` is not enabled, the event ID is missing, so
the function is shown instead (with an `f:` prefix as above). Since the ID is
generally the same as the function name, this does not matter much.
The event type is decoded by the symbol used by U-Boot for the event linker
list. Symbols have the form::
_u_boot_list_2_evspy_info_2_EVT_MISC_INIT_F
so the event type can be read from the end. To manually list spy information
in an image, use $(CROSS_COMPILE)nm::
nm u-boot |grep evspy |grep list
00000000002d6300 D _u_boot_list_2_evspy_info_2_EVT_MISC_INIT_F
Logging is also available. Events use category `LOGC_EVENT`, so you can enable
logging on that, or add `#define LOG_DEBUG` to the top of `common/event.c` to
see events being sent.
Dynamic events
--------------
Static events provide a way of dealing with events known at build time. In some
cases we want to attach an event handler at runtime. For example, we may wish
to be notified when a particular device is probed or removed.
This can be handled by enabling `CONFIG_EVENT_DYNAMIC`. It is then possible to
call `event_register()` to register a new handler for a particular event.
Dynamic event handlers are called after all the static event spy handlers have
been processed. Of course, since dynamic event handlers are created at runtime
it is not possible to use the `event_dump.py` to see them.
At present there is no way to list dynamic event handlers from the command line,
nor to deregister a dynamic event handler. These features can be added when
needed.
|
