Current Server Time: 23:17 (Central Europe)

#apertus IRC Channel Logs

2021/02/16

Timezone: UTC


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