U-Boot machine/arch independent API for external apps
|
=====================================================
|
|
1. Main assumptions
|
|
- there is a single entry point (syscall) to the API
|
|
- per current design the syscall is a C-callable function in the U-Boot
|
text, which might evolve into a real syscall using machine exception trap
|
once this initial version proves functional
|
|
- the consumer app is responsible for producing appropriate context (call
|
number and arguments)
|
|
- upon entry, the syscall dispatches the call to other (existing) U-Boot
|
functional areas like networking or storage operations
|
|
- consumer application will recognize the API is available by searching
|
a specified (assumed by convention) range of address space for the
|
signature
|
|
- the U-Boot integral part of the API is meant to be thin and non-intrusive,
|
leaving as much processing as possible on the consumer application side,
|
for example it doesn't keep states, but relies on hints from the app and
|
so on
|
|
- optional (CONFIG_API)
|
|
|
2. Calls
|
|
- console related (getc, putc, tstc etc.)
|
- system (reset, platform info)
|
- time (delay, current)
|
- env vars (enumerate all, get, set)
|
- devices (enumerate all, open, close, read, write); currently two classes
|
of devices are recognized and supported: network and storage (ide, scsi,
|
usb etc.)
|
|
|
3. Structure overview
|
|
- core API, integral part of U-Boot, mandatory
|
- implements the single entry point (mimics UNIX syscall)
|
|
- glue
|
- entry point at the consumer side, allows to make syscall, mandatory
|
part
|
|
- helper conveniency wrappers so that consumer app does not have to use
|
the syscall directly, but in a more friendly manner (a la libc calls),
|
optional part
|
|
- consumer application
|
- calls directly, or leverages the provided glue mid-layer
|
