1. 24 Jul, 2021 1 commit
  2. 20 Jul, 2021 1 commit
    • Mitch Burnett's avatar
      repo restructure · f1ded566
      Mitch Burnett authored
      makefiles include the platform instead of having to define PLATFORM in the
      source or change `alpaca_platform.h` everytime
      f1ded566
  3. 18 Jul, 2021 4 commits
  4. 28 Jun, 2021 2 commits
  5. 27 Jun, 2021 2 commits
    • Mitch Burnett's avatar
      continue to move to more generalized rfpll programming · e734d7cd
      Mitch Burnett authored
      extend `alpaca_rfclks` methods to include readbacks for lmk/lmx, and to add
      support for generalized i2c packet lengts. This allows for supporting the lmk on
      the zcu111. Tested on all 3 platforms.
      
      All 3 platform files to program the lmk and lmx only differ in how the
      i2c/peripheral hardware is initialized and the number of plls their program
      (e.g., zcu111/zrf16 both have 2 lmx adc plls, zcu216/208 only have one).
      e734d7cd
    • Mitch Burnett's avatar
      commit some version of zcu111 rfclks before grouping implementations · 365f4def
      Mitch Burnett authored
      *does not compile* (shame on me), should have done an intermediate commit
      as soon as getting this zcu111 script to work, but began to move common
      functionality for all boards in `alpaca_rfclks` but wanted to track some specifc
      version of the zcu111
      365f4def
  6. 09 May, 2021 1 commit
    • Mitch Burnett's avatar
      patch scary tcs read file code a bit · 0f8a8e2d
      Mitch Burnett authored
      had a bug when comparing pll type look for the lmx, compared against the wrong
      enum and would have segfaulted.
      
      Also fixed number of lmk regsiters coming out for lmk04828b. Seems tics outputs
      136 instead of what I thought was 128, not sure where that came from.
      
      a little better read code in the while-loop to at least make sure we don't read
      off and access past the length we malloc'd
      0f8a8e2d
  7. 08 May, 2021 4 commits
    • Mitch Burnett's avatar
      read TICS hex dump files as function and common program pll · fc97e667
      Mitch Burnett authored
      *Extend `rfclks` module to have a common program method callable to program an
      lmk (on the zcu216/208 and HTG boards -- need to check on zcu111) or an lmx
      
      * Move implementation of reading TICS text file to a common module method.
        implement the difference between reading an LMK and LMX (i.e., setup program
        sequence for LMX since it requires to duplicate and apply reset)
      
      * update `prg_pll`, `zcu216_rfclks` and `htg_rfclks` to use the new common
        methods
      
      * extend `prg_pll` to program either the zcu216 lmk or lmx with a command line
        switch
      
      * still need to implement a readback
      fc97e667
    • Mitch Burnett's avatar
      919a3522
    • Mitch Burnett's avatar
      include the htg config done for JH · 77aa7f3a
      Mitch Burnett authored
      77aa7f3a
    • Mitch Burnett's avatar
      Attempt to consolodate platform definitions for rfplls · 72023b65
      Mitch Burnett authored
      (also updates to continue to add i2c infrastructure and pynq2x2 definitions)
      
      Take all of the rfpll platform specific definitions from the test standalone and
      make a single header and implementations that builds definitions based on the
      rfsoc platform definition. A new platform header is used to be included for the
      different hardware peripherals (first i2c and now lmk/lmx plls).
      
      The implementation in the test files has not changed, just pulling out what can
      be consolodated. From here would be to continue to make clk programming methods.
      72023b65
  8. 07 Apr, 2021 2 commits
  9. 03 Apr, 2021 1 commit
  10. 31 Mar, 2021 2 commits
    • Mitch Burnett's avatar
      update i2c slave struct to include parent bus · a8b1a4fb
      Mitch Burnett authored
      The struct really represents a i2c device sitting on a mux more than a generic
      i2c device. This struct and i2c write/read methods would not work because they
      expect to write to a mux to talk to a device
      a8b1a4fb
    • Mitch Burnett's avatar
      add i2c0 file descriptor and identify i2c-mux problem, add proper i2c bus close · bdd6badb
      Mitch Burnett authored
      Making an i2c driver that is extendable has its problems when needing to be
      versatile to different scenarios and configurations. In this context is the i2c
      coniguration for the rfsoc boards where the mpsoc has i2c buses each with mux to
      extend attached i2c devices. For the rf clocking htg uses i2c0 and xilinx eval
      boards use i2c1. The inital code only targeted i2c1 and now really need both.
      
      Not just in the context of the rf clocks either, but all board i2c peripherals.
      So it makes sense to just always instance both since generally both busses are
      configured in mpsoc boards (although not guaranteed).
      
      So staging these commits before I start hacking and testing a way to determine
      parent device. My first thought is to just have a parent fd object in my struct
      but I am not sure if this will cause problems when a device doesn't sit on a
      mux.
      bdd6badb
  11. 29 Mar, 2021 5 commits
  12. 21 Mar, 2021 1 commit
    • Mitch Burnett's avatar
      Initial commit of test i2c utils for ALPACA infrastructure · 9db6da4c
      Mitch Burnett authored
      * alpaca_i2c_utils.h - definition of i2c device and enum of attached i2c devices
      * alpaca_i2c_utils.c - Implementation of i2c write, read, and read with repeated
        start (read after write) and simple main testing the functionality by
        read/writing from/to eeprom and the idt8a34001
      * idt8a34001_regs.c/h - definition of the registers for programming the idt8a34001
      
      These should be general purpose enough that potentially could merge support for
      HTG LMK/LMX clocking. Could also do the same for teh CLK104 board. However, that
      board has the gpio expander that would also need to be toggled which is not
      specifically i2c releated and so if to include CLK104 would be a hierarchy
      dependency.
      9db6da4c