quartiq / kasli-i2c Goto Github PK

What content is intended to be placed in the following EEPROM fields:

• vendor_data
• project_data
• user_data
• board_data?

According to comments in the code, the vendor_data field might be used for storing board serial number or data. However, I see no suggestion what to place in the other three fields. Were they reserved with something specific in mind and if so, has any specific format for it been developed? Or perhaps those fields were created just for 'future development'?

I guess I found the reason why the FPGA couldn't load its configuration from flash when reset (see the no CDONE issue sinara-hw/Fastino#48 (comment))

The lines below need to be swapped - according to the expander datasheet (p. 9) after the enable command is sent, the GPIO ports are configured as quasi-bidirectional, so when the creload function is invoked the CDONE pin is strongly driven low so the FPGA is not able to finish its configuration.

Trying to use kasli-i2c on a Kasli v1.1 since 1b86a25 gives errors like

Traceback (most recent call last):
  File "/miniconda/envs/devenv/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/miniconda/envs/devenv/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/workspace/kasli_get_mac.py", line 21, in <module>
    with bus.enabled("LOC0"):
  File "/miniconda/envs/devenv/lib/python3.8/contextlib.py", line 113, in __enter__
    return next(self.gen)
  File "/workspace/kasli.py", line 44, in enabled
    self.enable(*ports)
  File "/workspace/kasli.py", line 40, in enable
    self.write_single(addr, bits[addr])
  File "/workspace/i2c_bitbang.py", line 221, in write_single
    raise I2CNACK("Address Write NACK", addr)
pyftdi.i2c.I2cNackError: [Errno Address Write NACK] 112

@jordens am I right in thinking that this relates to hardware changes for v2.0? AFAICT for v2.0 we added a second I2C reset line going to the FPGA. This is ORd with the FT232 RESET line using FETs, resulting in a polarity inversion compared with v1.x. i.e. on v1.1 BDBUS 5 directly drives the active-low TCA9548 reset, while on v2.x it drives it via an inverter, so BDBUS 5 is active-high reset.

The current code reflects an active-high reset

The previous code reflects an active-low reset

Does that sound about right @jordens or have I got the wrong end of the stick? If so, do you have preferences on a fix (e.g. pass a reset polarity param into I2C's constructor that's set based on a kasli hw-rev)?

Since eblot/pyftdi@5d4be11#diff-59506818c26b3ffbf38ab767bc9a080c528daee33643289110907e757fa60df1

This means that kasli-i2c no longer runs on the current version of pyftdi that ships from conda-forge. Should we update this tool to match the latest?

what's the status of phaser flashing here? The code looks to be implemented (although missing a nice CLI, but that's easy to add) but this with False makes it look like the codepath can never be reached unless I'm missing something?