Skip to content

API for external applications

Rafal Jaworowski u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest7 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/7eth_receive() for standalone receiving Ethernet framenet/eth.c net/net.c+58 -00 replies
1/7eth_receive() for standalone receiving Ethernet framenet/eth.c net/net.c+58 -00 replies
2/7Simplify base address handling in bd_infoinclude/asm-ppc/u-boot.h+6 -110 replies
3/7Globalize envmatch()common/cmd_nvedit.c+2 -30 replies
4/7API header fileinclude/api_public.h+102 -00 replies
5/7Core API (U-Boot side)api/Makefile api/api.c api/api_net.c +2 more+1268 -00 replies
6/7External application demoapi_examples/Makefile api_examples/crt0.S api_examples/demo.c +2 more+1002 -00 replies
7/7Enable API_CONFIG for MPC8555CDSinclude/configs/MPC8555CDS.h+4 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [U-Boot-Users] [PATCH 0/7] API for external applications

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