| commit | aec377cdac19b31e106fdba544dc935060b5f428 | [log] [tgz] |
|---|---|---|
| author | Mohan Srinivasan <srmohan@google.com> | Mon Sep 24 11:47:34 2018 -0700 |
| committer | Mohan Srinivasan <srmohan@google.com> | Mon Sep 24 13:02:58 2018 -0700 |
| tree | b52b27f2d3b145b1682d93807ce7f2fe46458c90 | |
| parent | 6359964106009b99e3152f35154c611a512392f8 [diff] |
[dev][nand][aml-rawnand] Handle (read) DMAs being aborted. From the data we have, it seems clear that in the event of high data bus contention, NAND read DMA operations get aborted. The data DMA is aborted and the DMA of the read completion state is never done. This means the driver cannot rely on the read completion state being accurate or correct. Pre-initialize the read completion state with "bad" values, So that if the DMA is aborted, and the read completion state is never posted to memory, then we fail the read. The read is retried from the NAND protocol layer. Bug: ZX-2616. Test: Run Ricardo's read verification test (with a higher number of reads per block, running in a forever loop), with Ruchira's code to do sdio reads in the background once every 100us. Verified that the DMAs are aborted by pre-seeding the data buffer in the NAND controller driver with a known value, and seeing that same value posted back to the application in a "successful" read (before this change in place). Change-Id: Ia0d27af53ce2535302eac6f9985bf7b4edc474fb
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.