#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Bertl_zZ: I updated the pic16 firmware to the version found here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/i2c_slave.hex

anuejn: ah, just realized that you are reading/writing offset 0x0 instead of offset 0xF

`i2ctransfer -y 3 r1@0x4F` also results in 0x0F

what does i2cget -y -a -r 2 0x4F say?

Error: Unsupported option "-r"!'

give me a second to check on the remote beta ...

i2cdetect -y -a -r 2

can you upload the output somewhere?

okay, this looks at least as it should be :)

it seems none of the remote betas is working at the moment

uh sad

should be resolved shortly

axiom_prep_icsp.sh

wget http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/i2c_slave.hex

axiom_rf_sel.py B

axiom_rf_sel.py A

I get the expected 0x00

replies with the ID of the MachXO2 RF

axiom_pic_jtag_id.py A

in your case, it should find the MachXO2 on the secondary interface

thanks

I think I used i2cget wrong

I guess your firmware interprets that as a write byte?

and yes, that is a write because when you have registers, the register index needs to be written

(we do not have registers on the PIC, just addresses)

(I thought you meant registers when you said address 0x0F)

yeah, I only today realized that this might be the confusion ...

I guess I need a .cfg file to load the machxo with axiom_pic_jtag_prog.py?

the pic_jtag_prog is outdated and somewhat buggy

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/pic_jtag_sram.py

this could/should also work for SRAM uploads

so I just give it a .bit file?

(but it might be outdated)

check with bluez, he should have a python script which is recent and works with the bitstream

bluez: can you help me here?

https://drive.google.com/drive/folders/1QJZMhZqW7sk8I5WcuahM6Y1y5PdeoF2-?usp=sharing

i do not remember what the python scripts expect (yes probably cfg), but you can get that using the scripts

hm... somehow I cannot get the gawk script to work :(

the sram.svf is likely empty

and with empty I mean it doesn't contain any bitstream data

that doesn't look too bad

Ah but when I give the gawk script the bitstream for the flash it outputs something :)

Bertl: @integrate driver: sure, just need to check why the driver reads bogus data and not initialized properly if it is pre loaded and 'then' the overlay is loaded... have to reload the driver for it to work...

IIRC, we did an SRAM upload via python at some point

i suppose we did... lemme check, my memory fails me ':D

had this one at the remote beta but its there no more.. so i'm not sure if this needs any modification.. will need to check

ok then i'll try to get those integrated

Bertl: also, how do you think we should integrate the driver? anuejn and I were thinking to keep it as a submodule or something... and copy the source files to the kernel tree, while also patching the Kconfig and a certain Makefile for the compile option...?

does it need kernel patches?

the required patches (like the dynamic overlay etc.) are already on the patches directory

@out-of-tree: i suppose so..

(what I did: https://paste.niemo.de/kocugufogu.sh)

1111 suggests that the input is always high after the pass through

that smells a bit like a connection issue as your pass gateware enables pullups

what does axiom_pac1720_info.sh show?

when I unplug the usb3 module the current consumption on the PCIE_N_V rail drops

so do you have any idea what could be wrong?

Hm... it is build from the files you linked

yup

(modified to work with diamond 3.12)

was trying to find one of those rare USB plugin boards without additional debug cables ... but couldn't find one, so the one I have with debig cabling will have to do for a test

ok nice :)

should I try to reproduce my test there?

KeyError: '11111111111111111111111111111111'

but I'm not sure the test is valid, as the beta-c doesn't show any power on the modules

beta-a only has limited rail monitoring

thanks :)

okay, missing regulators added ...

nice :)

I wonder if the port bits are set accordingly on the PIC

need to adjust the i2c_slave.c accordingly

anuejn: what was the fw 2.x fix for python smbus not detecting the board revision correctly?

https://github.com/apertus-open-source-cinema/axiom-firmware/issues/144

nevermind, I was on the wrong beta :)

tris bits?

ah I see

looks good to me, yes

ah sorry I was confused

hm... but you did have a working version once?

okay no stress :)

let me adjust that quckly ...

let me upload the changes and explain what you need to adapt on your board

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pass_jtag_usb3/

there is a PASS_JTAG_USB3.info which describes the pin passing

make sure that the i2c_slave.c is also built for your main board version

so I need to rebuild the bitstream but the firmware on the pic16 can stay?

MB 0.34 or later vs MB 0.33 or earlier

but I am still investigating

anuejn: your MB is 0.34 no?

so you need to adjust the port A tris value

off to bed, good night

Bertl: still getting all ones

let's see what i2c2_get 0x61 and i2c2_get 0x65 gives

interesting ...

0xad

[0x61] = 0x92, [0x65] = 0x3d and [0x67] = 0xbd

i.e. the 0x80 are not relevant, and 0x12 becomes 0x30

and more interestingly TMS (0x10) in register B also differs

hm... I have to admit that I am a bit lost

I used the axiom_pic_jtag_load.py script. presumably it only loads the bitstream into sram

(but that seems to work; I tested that by tieing io pins to constant values and probed them with a multimeter)

axiom_pic_jtag_prog.py pass_jtag_usb3_1200.cfg pass_jtag_usb3_1200.ufm

that worked but didnt fix the problem

this will reset the pic and the RFW

well, you might now see the RFW in the id

so you still need to setup the tris and switch to the secondary

thanks a lot for the help :):):)

but simply using the south I/O ports there should make that work as well

you might be even clever and mix the two inputs

sounds... wild

the only two inputs are TDO and DONE

combining the ports from both slots with 'AND' should give the expected results :)