| commit | 6359964106009b99e3152f35154c611a512392f8 | [log] [tgz] |
|---|---|---|
| author | Brijen Raval <braval@google.com> | Thu Sep 20 13:09:55 2018 -0700 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Mon Sep 24 19:48:17 2018 +0000 |
| tree | 32e57a77ccc590944063706235cc0062c5bcf0a7 | |
| parent | 96d583d03dfe49fab08a2572be3bc59acfa28061 [diff] |
[vim][ethernet] Re-write ETH driver using new design
This CL breaks the Ethernet driver into 3 parts
1. ETH_BOARD: This driver has all the board specific
initialization and ops. Currently this driver
loads the DWMAC driver and it's hard coded.
In my next CL I will be getting that information
through the metadata.
2. ETH_MAC: This driver has all the MAC specific init and
ops. Same as above, currently hard coded to load
a particular PHY driver. In my next CLs I will get
that information from the metadata and also be adding
new ops. for PHY to register callbacks.
Currently the PHY config part is part of this driver,
it will be cleaned up in next CL.
Also need to add new ops. such that we support
multiple PHY's.
3. ETH_PHY: This is the PHY implementation. Currently it's not doing
much. In the next CL, we will be registering the callbacks
so MAC driver can call PHY APIs.
Design doc:
https://docs.google.com/document/d/1zoqTEJhWtvrQjUcE6pJ1JoaNpceU9nuCA7L9UuOMHso/edit#heading=h.xgjl2srtytjt
ZX-2686 #done
Test: Netboot on VIM2
Change-Id: I3e7202871d4649fa8139627d6d63b8d1f78f6775
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.