From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rafal Jaworowski <raj@semihalf.com>
Date: Wed, 3 Oct 2007 12:01:28 +0200
Subject: [U-Boot-Users] [PATCH 0/7] API for external applications
Message-ID: <20071003100126.GA1854@semihalf.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi,

This patchset attempts to implement an API for external applications, where
the existing jumptable mechanism is too simplified. We needed a more robust
and generic interface to access U-Boot resources for FreeBSD loader and came
up with this approach.

Patches 1-3 are changes in U-Boot infrastructure needed for the API purposes,
4-6 are bulk of this implementation, 7 is just enabling it for the MPC8555CDS
target (primary test platform).

- integrated with 1.3.0-rc2

- tested on PowerPC, but easily adaptable to other archs (only minor asm piece
  in the glue needs to be provided)

- devices: only tested networking on real target, storage code considered
  complete and exercised with test code, but needs more testing

- tested and integrated with FreeBSD native loader which runs on top of
  U-Boot as a stand-alone app (and in turn passes control to the kernel)

- API layer comes for the 8.5 KB increase in U-Boot's raw binary footprint


A couple of design notes:

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

Let me hear about comments on these patches; next I'd like to put them into my
FreeBSD-support custodian repo.

kind regards,
Rafal