1. 15 Aug, 2022 6 commits
  2. 30 Jul, 2022 2 commits
    • Mitch Burnett's avatar
      updates to rfsoc4x2 rfclks spi · f5fe1164
      Mitch Burnett authored
      realized rfsoc4x2 doesn't support LMK/LMX PLL readback beacsue the PLL
      `LD_STATUS` pins are pin strapped to only LEDs.
      The reamining spi code that was added is just convenient to keep around
    • Mitch Burnett's avatar
      addition of rfsoc4x2 platform and spi · b479462b
      Mitch Burnett authored
      tested to at least program the rfsoc4x2 and not break the zcu216. Read back is
      not currently working on rfsoc4x2 but seems to still be working on zcu216
      rfsoc4x2 uses spi directly while the other rfsoc boards have used an i2c to spi
      bridge. So this is a brute force hack to just get spi in there.
      might be worthwhile to rethink the implementation since it is becoming unweildy
      to have the different cases based on platform
  3. 05 May, 2022 1 commit
  4. 24 Jul, 2021 1 commit
  5. 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
  6. 18 Jul, 2021 4 commits
  7. 28 Jun, 2021 2 commits
  8. 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).
    • 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
  9. 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
  10. 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
      * extend `prg_pll` to program either the zcu216 lmk or lmx with a command line
      * still need to implement a readback
    • Mitch Burnett's avatar
    • Mitch Burnett's avatar
      include the htg config done for JH · 77aa7f3a
      Mitch Burnett authored
    • 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.
  11. 07 Apr, 2021 2 commits
  12. 03 Apr, 2021 1 commit
  13. 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
    • 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
  14. 29 Mar, 2021 5 commits
  15. 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