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