summaryrefslogtreecommitdiff
path: root/api/README
diff options
context:
space:
mode:
authorRafal Jaworowski <raj@semihalf.com>2008-01-09 19:39:36 +0100
committerRafal Jaworowski <raj@semihalf.com>2008-01-09 19:39:36 +0100
commit500856eb1707ed17d9204baa61dd59948d3b2899 (patch)
treee29338498cbf1b92ad496271e65934b890115545 /api/README
parent26a41790f8eba19ad450e18ae91351daf485b3e2 (diff)
downloadu-boot-500856eb1707ed17d9204baa61dd59948d3b2899.tar.gz
API for external applications.
This is an API for external (standalone) applications running on top of U-Boot, and is meant to be more extensible and robust than the existing jumptable mechanism. It is similar to UNIX syscall approach. See api/README for more details. Included is the demo application using this new framework (api_examples). Please note this is still an experimental feature, and is turned off by default. Signed-off-by: Rafal Jaworowski <raj@semihalf.com>
Diffstat (limited to 'api/README')
-rw-r--r--api/README55
1 files changed, 55 insertions, 0 deletions
diff --git a/api/README b/api/README
new file mode 100644
index 0000000000..c8f9c457c4
--- /dev/null
+++ b/api/README
@@ -0,0 +1,55 @@
+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