Current Server Time: 07:09 (Central Europe)

#apertus IRC Channel Logs

2021/02/16

Timezone: UTC


00:57
Obsdark
left the channel
01:13
BAndiT1983
changed nick to: BAndiT1983|away
03:34
Bertl_oO
off to bed now ... have a good one everyone!
03:34
Bertl_oO
changed nick to: Bertl_zZ
03:49
lexano
left the channel
03:50
lexano
joined the channel
04:19
eppisai
joined the channel
04:27
eppisai
left the channel
04:41
eppisai
joined the channel
05:44
BAndiT1983|away
changed nick to: BAndiT1983
05:51
BAndiT1983
changed nick to: BAndiT1983|away
06:42
se6ast1an
good day
07:29
eppisai
left the channel
07:47
eppisai
joined the channel
08:46
eppisai
left the channel
09:15
eppisai
joined the channel
09:20
BAndiT1983|away
changed nick to: BAndiT1983
09:23
EmilJ
left the channel
09:23
EmilJ
joined the channel
09:33
eppisai
left the channel
09:51
eppisai
joined the channel
10:37
anuejn
good day :)
10:37
anuejn
Bertl_zZ: I updated the pic16 firmware to the version found here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/i2c_slave.hex
10:38
anuejn
however I still get 0x0F from i2cget -y 3 0x40 0x0F
10:40
eppisai
left the channel
10:43
eppisai
joined the channel
10:55
Bertl_zZ
changed nick to: Bertl
10:55
Bertl
morning folks!
10:56
Bertl
anuejn: ah, just realized that you are reading/writing offset 0x0 instead of offset 0xF
10:56
Bertl
i.e. try 0x4F instead of 0x40
11:14
anuejn
`i2ctransfer -y 3 r1@0x4F` also results in 0x0F
11:16
Bertl
never used i2ctransfer
11:17
Bertl
what does i2cget -y -a -r 2 0x4F say?
11:17
Bertl
(assuming the pic is on bus 2)
11:17
anuejn
Error: Unsupported option "-r"!'
11:18
anuejn
without the -r it is 0x0F
11:18
Bertl
give me a second to check on the remote beta ...
11:18
anuejn
ok
11:20
Bertl
i2cdetect -y -a -r 2
11:20
Bertl
should list the PIC address ranges
11:21
Bertl
can you upload the output somewhere?
11:22
anuejn
https://termbin.com/bzl9
11:22
Bertl
okay, this looks at least as it should be :)
11:23
anuejn
(I have the kernel module for the i2c mux loaded; I have pb v0.22)
11:23
Bertl
it seems none of the remote betas is working at the moment
11:24
Bertl
have to double check
11:24
anuejn
uh sad
11:24
anuejn
thanks for your help in any case :)
11:24
Bertl
should be resolved shortly
11:31
Bertl
okay, so after doing the following steps:
11:32
Bertl
axiom_prep_icsp.sh
11:32
Bertl
axiom_rf_sel.py A
11:32
Bertl
wget http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/i2c_slave.hex
11:32
Bertl
axiom_icsp_prog.py A i2c_slave.hex
11:33
Bertl
axiom_rf_sel.py B
11:33
Bertl
axiom_icsp_prog.py B i2c_slave.hex
11:33
Bertl
axiom_rf_sel.py A
11:33
Bertl
i2c2_get 0x4F
11:33
Bertl
I get the expected 0x00
11:34
Bertl
axiom_pic_jtag_id.py A
11:34
Bertl
replies with the ID of the MachXO2 RF
11:34
Bertl
i2c2_set 0x4F 1
11:35
Bertl
axiom_pic_jtag_id.py A
11:35
Bertl
replies with all zeroes here, because there is nothing on the secondary jtag interface
11:36
Bertl
in your case, it should find the MachXO2 on the secondary interface
11:36
Bertl
I tried this on remote beta-c so you can logon there and compare if necessary
11:39
anuejn
thanks
11:39
Bertl
no problem
11:39
anuejn
I think I used i2cget wrong
11:40
anuejn
`i2cget -y 2 0x4F` results in 0x00 while `i2cget -y 2 0x4F 0x0F` results in 0x0F
11:41
anuejn
I guess your firmware interprets that as a write byte?
11:41
Bertl
ah, yes, that would be an additional register byte
11:41
Bertl
and yes, that is a write because when you have registers, the register index needs to be written
11:42
anuejn
That makes sense
11:42
Bertl
(we do not have registers on the PIC, just addresses)
11:42
Bertl
(which is mainly for performance reasons :)
11:42
anuejn
(I thought you meant registers when you said address 0x0F)
11:42
anuejn
I see
11:43
Bertl
yeah, I only today realized that this might be the confusion ...
12:00
anuejn
Bertl: where do I get the jed2cfg.gawk script from?
12:00
anuejn
I guess I need a .cfg file to load the machxo with axiom_pic_jtag_prog.py?
12:09
Bertl
it's probably better to use the driver to program the MachXO2
12:09
Bertl
the pic_jtag_prog is outdated and somewhat buggy
12:10
anuejn
hm... I got that to work but I didnt manage to talk to the plugged in plugin module
12:11
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/pic_jtag_sram.py
12:11
anuejn
so I wanted to rule out issues with the driver and try it with the python scripts
12:11
Bertl
this could/should also work for SRAM uploads
12:11
Bertl
note, it uses the burst bitstream directly
12:12
anuejn
so I just give it a .bit file?
12:12
Bertl
(which is the correct way to do an upload to SRAM)
12:13
Bertl
(but it might be outdated)
12:13
anuejn
hm... seems like it expects something different
12:14
Bertl
check with bluez, he should have a python script which is recent and works with the bitstream
12:15
anuejn
okay :)
12:15
anuejn
bluez: can you help me here?
12:19
bluez
anuejn: lemme check.. it's been quite a while...
12:26
bluez
https://drive.google.com/drive/folders/1QJZMhZqW7sk8I5WcuahM6Y1y5PdeoF2-?usp=sharing
12:26
bluez
here are some scripts mentioned in those Makefiles
12:27
bluez
i do not remember what the python scripts expect (yes probably cfg), but you can get that using the scripts
12:31
Bertl
bluez: it would be great if you could find some spare time to integrate the driver and maybe the python upload scripts into fw 2.x with vup/anuejn
12:31
anuejn
hm... somehow I cannot get the gawk script to work :(
12:32
anuejn
`gawk -f svf2cfg.gawk rfw_pass_sram.svf` just outputs nothing
12:32
Bertl
the sram.svf is likely empty
12:32
Bertl
this seems to be a bug in the Lattice tools
12:33
Bertl
and with empty I mean it doesn't contain any bitstream data
12:33
anuejn
it has this content: https://termbin.com/alv3
12:34
Bertl
that doesn't look too bad
12:34
Bertl
but it doesn't look like the format I remember either
12:34
anuejn
Ah but when I give the gawk script the bitstream for the flash it outputs something :)
12:35
anuejn
thanks :)
12:37
bluez
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...
12:37
bluez
Bertl: @python upload scripts: which ones?
12:38
Bertl
IIRC, we did an SRAM upload via python at some point
12:38
Bertl
basically as test run for the driver, where you found and fixed a jtag error
12:40
bluez
i suppose we did... lemme check, my memory fails me ':D
12:54
bluez
was it this one: https://drive.google.com/file/d/1DhndZADackxZ_VnTuFQtXHDXZE8vfNWE/view?usp=sharing
12:56
bluez
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
13:01
bluez
this one is a backup i had
13:01
bluez
ok then i'll try to get those integrated
13:03
Bertl
looks good
13:05
bluez
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...?
13:05
bluez
Bertl: okay
13:06
Bertl
does it need kernel patches?
13:07
Bertl
otherwise building it as out-of-tree module should be fine, no?
13:07
bluez
the required patches (like the dynamic overlay etc.) are already on the patches directory
13:07
anuejn
somehow even after all that jtag dance I only get '11111111111111111111111111111111' as an idcode :(
13:08
bluez
@out-of-tree: i suppose so..
13:09
Bertl
i'll see if I can find an USB plugin module and test it on one of the remote betas
13:10
anuejn
(what I did: https://paste.niemo.de/kocugufogu.sh)
13:10
bluez
also, you said something about the gpio expander kernel driver claiming the addresses... and the scripts not being able to use them while the driver was loaded.. will that be an issue?
13:11
Bertl
1111 suggests that the input is always high after the pass through
13:12
Bertl
anuejn: is the MachXO2 on the plugin powered?
13:13
anuejn
that smells a bit like a connection issue as your pass gateware enables pullups
13:13
anuejn
Bertl: how can I check?
13:14
Bertl
what does axiom_pac1720_info.sh show?
13:15
anuejn
https://termbin.com/20tt
13:17
anuejn
when I unplug the usb3 module the current consumption on the PCIE_N_V rail drops
13:52
Bertl
looks good
13:55
anuejn
so do you have any idea what could be wrong?
13:56
Bertl
maybe the pass code is not correct?
14:01
anuejn
Hm... it is build from the files you linked
14:02
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pass_jtag/ <- this one?
14:03
anuejn
yup
14:03
Bertl
and your mainboard version is?
14:03
anuejn
(modified to work with diamond 3.12)
14:04
anuejn
mainboard v0.34 r1.0
14:20
Bertl
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
14:21
Bertl
will add it to beta-c
14:25
anuejn
ok nice :)
14:27
Bertl
done
14:27
anuejn
should I try to reproduce my test there?
14:28
anuejn
also is the plugin connected to the north pcie?
14:37
BAndiT1983
changed nick to: BAndiT1983|away
14:43
Bertl
okay, seems I can reproduce the issue here
14:43
Bertl
KeyError: '11111111111111111111111111111111'
14:44
vnksnkr
joined the channel
14:45
Bertl
but I'm not sure the test is valid, as the beta-c doesn't show any power on the modules
14:45
Bertl
have to check whether the beta-c even has LDOs for those rails :)
14:49
eppisai
left the channel
14:50
Bertl
prep_icsp completely fails on beta-b ...
14:51
Bertl
beta-a only has limited rail monitoring
14:54
Bertl
okay, the beta-c is missing the regulators, but I might have some spares, will see what I can do
14:55
anuejn
thanks :)
14:57
anuejn
huh I guess I will try to measure the power on the plugin module with a multimeter then
15:13
eppisai
joined the channel
15:13
vnksnkr
left the channel
15:34
Bertl
okay, missing regulators added ...
15:37
Umori_
left the channel
15:41
anuejn
nice :)
15:48
Bertl
so now I can reproduce the issue with power on the rails :)
15:55
Bertl
I wonder if the port bits are set accordingly on the PIC
16:01
Bertl
okay, I have main board version 0.33 here, which means that the PIC pinout is different
16:01
Bertl
need to adjust the i2c_slave.c accordingly
16:10
BAndiT1983|away
changed nick to: BAndiT1983
16:10
Bertl
anuejn: what was the fw 2.x fix for python smbus not detecting the board revision correctly?
16:11
Bertl
something related to the smbus package version or so ...
16:12
Bertl
https://github.com/apertus-open-source-cinema/axiom-firmware/issues/144
16:12
Bertl
hmm, but pip says, smbus-cffi (and normal smbus) are installed ...
16:14
Bertl
nevermind, I was on the wrong beta :)
16:18
Bertl
so tris bits seem to be off at least for the pass through
17:00
anuejn
tris bits?
17:00
Bertl
they select which PIC pin is an output or input
17:00
anuejn
ah I see
17:00
anuejn
but the constraints file looks good?
17:01
Bertl
looks good to me, yes
17:01
anuejn
https://files.niemo.de/pass.cfg is the bitstream I was using
17:02
anuejn
ah sorry I was confused
17:02
anuejn
I thought the problem was the pass bitstream but you said that the problem is the pic firmware
17:03
anuejn
hm... but you did have a working version once?
17:04
Bertl
yeah, give me a few minutes to figure it out once again :)
17:06
anuejn
okay no stress :)
17:25
Bertl
hmm, seems the pass code is passing the wrong signals :)
17:26
Bertl
let me adjust that quckly ...
17:47
Bertl
okay, working now on the remote beta-c
17:47
Bertl
let me upload the changes and explain what you need to adapt on your board
17:49
anuejn
nice :)
18:01
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pass_jtag_usb3/
18:01
Bertl
check what MachXO2 is used on your main board (1200 vs 2000, on the beta-c it is the 2000)
18:02
Bertl
there is a PASS_JTAG_USB3.info which describes the pin passing
18:03
Bertl
it also contains the necessary TRIS settings
18:03
Bertl
make sure that the i2c_slave.c is also built for your main board version
18:04
Bertl
(3.11 was the latest lattice version I had installed, so I tested with that)
18:08
anuejn
so I need to rebuild the bitstream but the firmware on the pic16 can stay?
18:09
Bertl
if your firmware was compiled for the correct mainboard, then yes
18:09
Bertl
MB 0.34 or later vs MB 0.33 or earlier
18:39
Bertl
off for now .. bbl ... drop me a note if there are any problems
18:39
Bertl
changed nick to: Bertl_oO
19:17
anuejn
so the symptoms havent changed yet
19:17
anuejn
but I am still investigating
20:11
eppisai
left the channel
20:38
Bertl_oO
changed nick to: Bertl
20:38
Bertl
back now ...
20:41
Bertl
anuejn: your MB is 0.34 no?
20:42
vup
yeah ist 0.34
20:42
Bertl
so you need to adjust the port A tris value
20:43
Bertl
i.e. instead of i2c2_set 0x60 0xEC you want to use i2c2_set 0x60 0xC7
20:48
se6ast1an
off to bed, good night
20:48
Bertl
nn
20:49
anuejn
Bertl: still getting all ones
20:49
Bertl
there might also be some false values in the latches
20:50
Bertl
let's see what i2c2_get 0x61 and i2c2_get 0x65 gives
20:51
anuejn
0x78 and 0x2d
20:54
Bertl
interesting ...
20:55
Bertl
let's check the port B values as well, they are on 0x67
20:56
anuejn
0xad
20:57
Bertl
so here is what I get on the remote beta-c:
20:57
Bertl
[0x61] = 0x92, [0x65] = 0x3d and [0x67] = 0xbd
20:57
Bertl
now the port A values need to be shifted according to the pin changes
20:59
Bertl
i.e. the 0x80 are not relevant, and 0x12 becomes 0x30
20:59
Bertl
so for you TDI is set to '1' while it is '0' here after a script run
21:00
Bertl
and more interestingly TMS (0x10) in register B also differs
21:00
Bertl
script being: 'axiom_pic_jtag_id.py A'
21:01
anuejn
hm... I have to admit that I am a bit lost
21:01
Bertl
did you only load the pass through into the RFW SRAM or have you programmed it into the flash?
21:02
anuejn
I used the axiom_pic_jtag_load.py script. presumably it only loads the bitstream into sram
21:03
Bertl
okay, it might be possible that the RFW got reset
21:03
anuejn
(but that seems to work; I tested that by tieing io pins to constant values and probed them with a multimeter)
21:03
Bertl
try with axiom_pic_jtag_prog.py instead (and the .cfg/.ufm)
21:04
Bertl
axiom_pic_jtag_prog.py pass_jtag_usb3_1200.cfg pass_jtag_usb3_1200.ufm
21:05
Bertl
this will at least rule out any issues with an RFW reset
21:13
anuejn
that worked but didnt fix the problem
21:13
Bertl
try to rf_sel B and then back to A
21:13
Bertl
this will reset the pic and the RFW
21:15
anuejn
it worked :)
21:15
Bertl
well, you might now see the RFW in the id
21:16
anuejn
(however the fail was also that the plugin module was in the wrong slot from a previous test)
21:16
Bertl
so you still need to setup the tris and switch to the secondary
21:16
anuejn
no it is a board with a different machxo :)
21:16
anuejn
thanks a lot for the help :):):)
21:16
Bertl
ah, well, it won't work on the south slot without a different pass gateware
21:17
Bertl
but simply using the south I/O ports there should make that work as well
21:17
anuejn
yup I build a modified pass gateware
21:17
Bertl
you might be even clever and mix the two inputs
21:18
Bertl
to get a version which works in either slot as long as there is only one module plugged in :)
21:18
anuejn
sounds... wild
21:18
Bertl
outputs can be routed to both slots
21:18
Bertl
the only two inputs are TDO and DONE
21:19
Bertl
all have pull ups, so only a '0' is relevant
21:19
Bertl
combining the ports from both slots with 'AND' should give the expected results :)
21:20
Bertl
anyway, glad it works now ...
22:46
aombk2
joined the channel
22:50
aombk
left the channel