代码拉取完成,页面将自动刷新
同步操作将从 Gitee 极速下载/u-boot 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
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
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。