Fork of the vendor (Boundary Devices) u-boot for Reform 2, with minor tweaks. The goal is to migrate to mainstream u-boot or barebox ASAP. The main impediment so far is the 4GB RAM config.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.
 
 
 
 
 
 
Heiko Schocher 5025897774 powerpc, 5xx: remove support for 5xx 4 years ago
..
Kconfig kconfig: Add API kconfig file 4 years ago
Makefile api: Add FreeBSD API support for MIPS platforms 5 years ago
README Coding Style cleanup; update CHANGELOG 13 years ago
api.c api: Use hashtable function for API_env_enum 4 years ago
api_display.c Add GPL-2.0+ SPDX-License-Identifier to source files 8 years ago
api_net.c api: Disable api_net when DM is used 4 years ago
api_platform-arm.c Add GPL-2.0+ SPDX-License-Identifier to source files 8 years ago
api_platform-mips.c api: Add FreeBSD API support for MIPS platforms 5 years ago
api_platform-powerpc.c powerpc, 5xx: remove support for 5xx 4 years ago
api_private.h Add GPL-2.0+ SPDX-License-Identifier to source files 8 years ago
api_storage.c Kconfig: Add a CONFIG_IDE option 4 years ago

README

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