1U-Boot machine/arch independent API for external apps 2===================================================== 3 41. Main assumptions 5 6 - there is a single entry point (syscall) to the API 7 8 - per current design the syscall is a C-callable function in the U-Boot 9 text, which might evolve into a real syscall using machine exception trap 10 once this initial version proves functional 11 12 - the consumer app is responsible for producing appropriate context (call 13 number and arguments) 14 15 - upon entry, the syscall dispatches the call to other (existing) U-Boot 16 functional areas like networking or storage operations 17 18 - consumer application will recognize the API is available by searching 19 a specified (assumed by convention) range of address space for the 20 signature 21 22 - the U-Boot integral part of the API is meant to be thin and non-intrusive, 23 leaving as much processing as possible on the consumer application side, 24 for example it doesn't keep states, but relies on hints from the app and 25 so on 26 27 - optional (CONFIG_API) 28 29 302. Calls 31 32 - console related (getc, putc, tstc etc.) 33 - system (reset, platform info) 34 - time (delay, current) 35 - env vars (enumerate all, get, set) 36 - devices (enumerate all, open, close, read, write); currently two classes 37 of devices are recognized and supported: network and storage (ide, scsi, 38 usb etc.) 39 40 413. Structure overview 42 43 - core API, integral part of U-Boot, mandatory 44 - implements the single entry point (mimics UNIX syscall) 45 46 - glue 47 - entry point at the consumer side, allows to make syscall, mandatory 48 part 49 50 - helper conveniency wrappers so that consumer app does not have to use 51 the syscall directly, but in a more friendly manner (a la libc calls), 52 optional part 53 54 - consumer application 55 - calls directly, or leverages the provided glue mid-layer 56