From: Rafal Jaworowski <raj@semihalf.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH 0/7] API for external applications
Date: Wed, 3 Oct 2007 12:01:28 +0200 [thread overview]
Message-ID: <20071003100126.GA1854@semihalf.com> (raw)
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
next reply other threads:[~2007-10-03 10:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-03 10:01 Rafal Jaworowski [this message]
2007-10-03 10:03 ` [U-Boot-Users] [PATCH 1/7] eth_receive() for standalone receiving Ethernet frame Rafal Jaworowski
2007-10-03 10:04 ` [U-Boot-Users] [PATCH 2/7] Simplify base address handling in bd_info Rafal Jaworowski
2007-10-03 10:05 ` [U-Boot-Users] [PATCH 3/7] Globalize envmatch() Rafal Jaworowski
2007-10-03 10:06 ` [U-Boot-Users] [PATCH 4/7] API header file Rafal Jaworowski
2007-10-03 10:07 ` [U-Boot-Users] [PATCH 5/7] Core API (U-Boot side) Rafal Jaworowski
2007-10-03 10:07 ` [U-Boot-Users] [PATCH 6/7] External application demo Rafal Jaworowski
2007-10-03 10:08 ` [U-Boot-Users] [PATCH 7/7] Enable API_CONFIG for MPC8555CDS Rafal Jaworowski
2007-10-03 12:35 ` [U-Boot-Users] [PATCH 1/7] eth_receive() for standalone receiving Ethernet frame Rafal Jaworowski
2007-10-03 14:45 ` [U-Boot-Users] [PATCH 0/7] API for external applications Marcel Moolenaar
2007-10-04 15:52 ` Haavard Skinnemoen
2007-10-04 16:33 ` Marcel Moolenaar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071003100126.GA1854@semihalf.com \
--to=raj@semihalf.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox