12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455 |
- 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
|