u-boot/api
Tom Rini 6a7185887b global: Make <asm/global_data.h> include <asm/u-boot.h>
This follows the example of RISC-V where <asm/global_data.h> includes
<asm/u-boot.h> directly as "gd" includes a reference to bd_info already
and so the first must include the second anyhow. We then remove
<asm/u-boot.h> from all of the places which include references to "gd"
an so have <asm/global_data.h> already.

Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-06 15:07:48 -06:00
..
api_display.c api: Drop LCD implementation 2022-10-30 20:07:16 +01:00
api_net.c SPDX: Convert all of our single license tags to Linux Kernel style 2018-05-07 09:34:12 -04:00
api_platform-arm.c global: Make <asm/global_data.h> include <asm/u-boot.h> 2024-05-06 15:07:48 -06:00
api_platform-mips.c global: Make <asm/global_data.h> include <asm/u-boot.h> 2024-05-06 15:07:48 -06:00
api_platform-powerpc.c global: Make <asm/global_data.h> include <asm/u-boot.h> 2024-05-06 15:07:48 -06:00
api_private.h common: board_r: Drop initr_api wrapper 2021-01-15 14:36:12 -05:00
api_storage.c scsi: Forceably finish migration to DM_SCSI 2023-11-07 18:36:06 -05:00
api.c common: board_r: Drop initr_api wrapper 2021-01-15 14:36:12 -05:00
Kconfig api: Rework menu, and make it depend on CC_IS_GCC 2023-04-25 15:31:28 -04:00
Makefile SPDX: Convert all of our single license tags to Linux Kernel style 2018-05-07 09:34:12 -04:00
README Coding Style cleanup; update CHANGELOG 2008-01-10 00:55:14 +01:00

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