Upon updating certain components (the FPGA, for example), the
Peripheral Manager is restarted, and the overlay is reapplied. In order
to facilitate this, the RPC server intercepts and handles the
update_component function.
Tested on the RJ45 ethernet connection. It probably won't work as well
if the SFP connection goes down when the overlay is removed.
Previously, the daughterboard requested an overlay file based on SFP
preference using magic values. This commit moves the decision making to
the peripheral manager, which uses our singular name (ie 'n3xx' for the
N310).
Paths to the component files is now stored in the updateable_components
dictionary. This makes them accessible in the base class, and generally cleans
up the member variables.
- The MPM function update_component now accepts multiple components to
be updated in one RPC call.
- Updated the property tree and image loader to match this change.
- Also added DTS loading to the image loader.
- re-wrote portions of the LMK driver for flexible rates and configuration
- tweaked TDC driver for compatibility and ease of debugging
- updated comments and log statements throughout for uniformity
Now, when claiming a device, the connection type will be stored as a
string in PeriphManagerBase. This way we can read out the current
connection type even when not currently inside an RPC call.
-update_fpga loads the FPGA image from the base class's update_component function
-checks if FPGA image is a bit or bin file, and converts to Zynq-compatible binfile if necessary
-update_component takes a byte array containing the data to be written,
and a dictionary containing the metadata of the component to be
updated
-The metadata must contain 'id' and 'filename'
-The metadata may contain an md5 hash ('md5')
An N310 device will query all its dboards for ref lock status and
return a Boolean combination as a motherboard sensors (note: the N310
does not actually have a ref_locked sensor on the motherboard, this is
mostly for backwards-compat with UHD applications that expect a
motherboard ref lock sensor).
- Motherboard sensors are automatically populated into the property
tree, they can be automatically enumerated and queried
- Daughterboard sensors have an API for querying and enumerating
sensors, but this commit does not automatically add them to the
property tree
This will enable both RevC and RevD from an MPM perspective. The
revision read back from the EEPROM is used to enable the code for either
rev.
The impact on the code is limited to the port expander GPIOs. Port
expander objects are instantiated in both the N310 MPM module as well as
the n3xx_bist executable.
When reading revision numbers from EEPROM, we now have an easy way of
checking of our version MPM is sufficient to run on the current device.
N310 implicitly makes use of this starting with this commit.
When there are no daughterboards present, clock and time source are
meaningless. It's also possible that corresponding FPGA images are not
loaded, in which case trying to set those could crash the system. Unless
daughterboards are actually present, these settings won't get applied
any more.
This makes the GPS reset go high by default (i.e., takes it out of reset
by default) and the init survey pin go high (i.e., take it out of survey
mode).
