02:24 | GrahamM | left the channel | |
03:02 | slikdigit | left the channel | |
03:04 | Bertl_oO | comradekingu: not yet
| |
03:04 | Bertl_oO | off to bed now ... have a good one everyone!
| |
03:04 | Bertl_oO | changed nick to: Bertl_zZ
| |
04:58 | John_K` | changed nick to: John_K
| |
07:05 | gnufan | joined the channel | |
08:04 | jucar | joined the channel | |
08:28 | jucar | left the channel | |
09:08 | intracube_ | changed nick to: intracube
| |
09:40 | John_K | hello
| |
09:42 | LordVan | joined the channel | |
09:47 | intracube | comradekingu: you don't need a voucher for the first payment
| |
09:52 | John_K | Bertl_zZ: when you're around, I have a svf for the lattice now, with icsp.bit loaded I can't seem to figure out how you load it
| |
09:53 | John_K | I assumed it would be pic_jtag_flash.py but it errors out on the first i2c write
| |
09:53 | John_K | by "how you load it" I mean, how you program the svf to the Lattice
| |
09:59 | intracube | comradekingu: I mean, you don't need to enter it
| |
10:18 | jucar | joined the channel | |
10:22 | Bertl_zZ | changed nick to: Bertl
| |
10:22 | Bertl | morning folks!
| |
10:23 | Bertl | John_K: you need to use the .jed file for the pic_jtag_flash.py
| |
10:23 | John_K | aha
| |
10:23 | Bertl | but you also need to adapt the script to the 640HC
| |
10:23 | John_K | it's still dieing before that on the first i2c write
| |
10:23 | John_K | let me gist it
| |
10:24 | Bertl | I have to run to the post office to get a package, I'll be back in half an hour or so
| |
10:24 | John_K | ok I'll likely be gone by then
| |
10:24 | John_K | but will check channel later
| |
10:24 | Bertl | hmm, okay, what output do you get?
| |
10:26 | John_K | https://gist.github.com/anonymous/2830eecf8ab10f2892a1
| |
10:27 | Bertl | ah, you get the error on the pic_jtag_id?
| |
10:27 | jucar | left the channel | |
10:28 | John_K | it's pretty much the same on _prog
| |
10:28 | John_K | err _flash rather
| |
10:28 | Bertl | did you select one of the FPGAs with ./icsp_sel.py
| |
10:28 | Bertl | option A or B is valid
| |
10:28 | John_K | yes, that's in there
| |
10:28 | John_K | B
| |
10:29 | John_K | this is the code that's dieing:
| |
10:29 | John_K | i2c = SMBus(2)
| |
10:29 | John_K | i2c.write_byte(0x38, 0x01) # TDO_W input
| |
10:29 | Bertl | i2cdetect -r -y -a 2 ?
| |
10:29 | Bertl | without the '?'
| |
10:29 | John_K | looks fine
| |
10:30 | John_K | 70 in lower left
| |
10:30 | Bertl | that's all?
| |
10:30 | John_K | yes
| |
10:30 | Bertl | if you have the pic programmed, it should show entries in row 10 and 30 as well
| |
10:30 | John_K | one sec
| |
10:30 | Bertl | (if the mux (70) is steered properly)
| |
10:31 | John_K | hrm
| |
10:31 | John_K | i re-programmed the pic to be sure, it programs fine but i2cdetect still returns the same thing
| |
10:31 | John_K | channel A looks to work
| |
10:31 | John_K | I get things in row 10 and 20
| |
10:31 | Bertl | 10 and 30
| |
10:32 | John_K | yes
| |
10:32 | John_K | and jtag id works there
| |
10:32 | Bertl | so that bus/pic is working
| |
10:32 | John_K | so, it looks like there is an issue with PIC A?
| |
10:32 | Bertl | note that you need to program both pics
| |
10:32 | John_K | it programs just fine
| |
10:32 | Bertl | does it detect the pic fine as well?
| |
10:33 | Bertl | ./icsp_picid.py
| |
10:33 | John_K | hrm, after I did that, picB now seems to work
| |
10:33 | John_K | very weird
| |
10:34 | Bertl | ./icsp_picid.py A
| |
10:34 | John_K | I had to switch to A, query it, then switch back and now B gives correct results on i2cdetect and pic_jtag_id
| |
10:34 | Bertl | ./icsp_picid.py B
| |
10:34 | John_K | they both work fine
| |
10:34 | John_K | now, anyway
| |
10:35 | Bertl | okay, then the flash should work as well, but you need to adapt it to the 640HC first
| |
10:35 | John_K | ok I think things are ok now
| |
10:35 | John_K | the flash script?
| |
10:35 | Bertl | yep, it wasn't tested yet with anything but a 2000
| |
10:35 | John_K | it has a 640hc devid in it
| |
10:36 | Bertl | yes, I added this for the future :)
| |
10:36 | John_K | any advice on what I'd need to change / look for?
| |
10:36 | John_K | ah :)
| |
10:37 | Bertl | page numbers, feature row comes to my mind
| |
10:37 | Bertl | anyway, really have to run now ... bbl
| |
10:37 | Bertl | changed nick to: Bertl_oO
| |
10:39 | John_K | ok, thanks
| |
10:47 | John_K | Bertl_oO: can you post your Jtag class? the jtag.py in /root doesn't have the Jtag class required by the pic_jtag_flash.py
| |
10:47 | John_K | I'm off to bed, will pick this up in 7 hours or so
| |
10:53 | aombk2 | joined the channel | |
10:56 | aombk | left the channel | |
11:28 | LordVan | left the channel | |
11:41 | Bertl_oO | changed nick to: Bertl
| |
11:41 | Bertl | back now ...
| |
12:48 | se6astian|away | changed nick to: se6astian
| |
13:49 | Bertl | off for a little ... bbl
| |
13:49 | Bertl | changed nick to: Bertl_oO
| |
15:14 | gnufan | left the channel | |
16:45 | se6astian | changed nick to: se6astian|away
| |
19:22 | LordVan | joined the channel | |
19:25 | Bertl_oO | changed nick to: Bertl
| |
19:25 | Bertl | back now ...
| |
19:28 | Bertl | John_K: ping me when you're around, I've updated most of the code for flashing the fpgas (should now work for the 640 as well)
| |
19:32 | jucar | joined the channel | |
20:13 | John_K | Bertl: hi
| |
20:14 | Bertl | hey, grab everything from ICSP
| |
20:15 | Bertl | then start with ./pic_jtag_id2.py
| |
20:18 | John_K | ok
| |
20:18 | Bertl | if that identifies and outputs proper info, the other files should work as well
| |
20:19 | Bertl | I switched from using the .jed file to an intermediate state where you generate .cfg and .ufm from the .svf.flash
| |
20:19 | John_K | ok, will get things setup and test
| |
20:20 | John_K | so the tools generate either a jedec or bitstream
| |
20:20 | John_K | you need to use a separate tool to generate svf
| |
20:20 | Bertl | correct, you got my makefile?
| |
20:20 | John_K | unless you're doing it differently somehow
| |
20:20 | John_K | apparently not
| |
20:20 | Bertl | ah, I see, sec
| |
20:21 | Bertl | btw, do you have some way to check that the FPGA works as intended? i.e. some logic analyzer or PMOD debug module or center solder on?
| |
20:24 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/
| |
20:26 | John_K | I can hookup a LA
| |
20:26 | Bertl | okay, just checking ...
| |
20:27 | John_K | I may be interested in implementing some code in that CPLD, we should talk about goals for it at some point
| |
20:27 | Bertl | sure, no problem
| |
20:27 | Bertl | it is also possible to run code on the PICs to some extend
| |
20:28 | Bertl | they have some connectivity throughout the main board
| |
20:28 | John_K | I'm more interested in the global shutter trigger that's hooked up to RFE
| |
20:29 | Bertl | it was one of the basic ideas to provide different programmable parts with the Beta so that crazy (or not so crazy) ideas can be realized
| |
20:29 | John_K | in the current state you could just replace PIC+CPLD with 5 wires
| |
20:29 | Bertl | yep, similar in the dummy interface board, which currently is "just wires"
| |
20:29 | John_K | true
| |
20:29 | Bertl | (and will be replaced by a proper FPGA solution later)
| |
20:35 | Bertl | ah, I forgot, I updated the PIC code, you have a new i2c_slave.c there, you need to build and programm it into the pics first
| |
20:35 | Bertl | cd /opt/PIC/PIC16/PIC16F1718/
| |
20:35 | Bertl | update the file and run make
| |
20:39 | John_K | aha thanks
| |
20:40 | John_K | oh, the code is already in the image, it just needs to be recompiled?
| |
20:40 | Bertl | yeah the i2c_slave.c needs to be updated though
| |
20:42 | John_K | ah, in the ICSP dir, got it
| |
20:49 | John_K | wrestling with flexlm on linux
| |
20:50 | Bertl | yeah, that's always annoying
| |
20:50 | John_K | I was using the windows version yesterday, just installed it in my linux machine to use your makefiles
| |
20:50 | John_K | and it doesn't want to seem to parse the new license file I got for it
| |
20:51 | John_K | checking to see if I need to install flexlm on its own or something
| |
20:51 | John_K | does synplify need to be licensed other than via "free diamond license"?
| |
20:52 | Bertl | everything should work with the free license
| |
20:52 | Bertl | but you can run the svf generating command on windows as well I guess?
| |
20:52 | John_K | ok, did you have to start a license server or set an environment variable?
| |
20:52 | Bertl | yes, I set a bunch of environment variables
| |
20:53 | John_K | ahh
| |
20:53 | Bertl | let me upload the script for that
| |
20:53 | John_K | many thanks
| |
20:54 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/env.sh
| |
20:55 | LordVan | left the channel | |
21:05 | John_K | well I had to install lsb, just to get lmutil to even start
| |
21:08 | Bertl | you can be happy that they support 64bit and you don't have to mess with 32bit libraries as well :)
| |
21:08 | John_K | well this is sort of that
| |
21:08 | John_K | ldd said all of the libraries were present, internet hinted at lsb
| |
21:43 | John_K | gah this still isn't working
| |
21:43 | John_K | &$%& DRM licensing crap
| |
21:48 | Bertl | shall I generate the .svf for 640HC for you?
| |
21:49 | Bertl | (i.e. evil ascii blob :)
| |
21:51 | John_K | if you wouldn't mind :)
| |
21:51 | John_K | will try spinning up a RedHat VM to see if Lattice crap works in that
| |
21:52 | Bertl | I'm using it on mageia, not a problem there
| |
21:52 | Bertl | was also testing centos in a container (worked as well)
| |
21:52 | John_K | mageia?
| |
21:52 | John_K | ok I'll try centos
| |
21:53 | jucar | left the channel | |
21:54 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/640/
| |
21:55 | Bertl | what version is your main board?
| |
21:58 | John_K | 0.33
| |
21:58 | Bertl | okay, then those are fine
| |
21:59 | Bertl | what you do now is the following:
| |
21:59 | Bertl | you use the svf2cfg.gawk and svf2ufm.gawk to create two files
| |
22:00 | Bertl | gawk -f svf2cfg.gawk pass.svf.flash >pass.cfg
| |
22:00 | Bertl | gawk -f svf2ufm.gawk pass.svf.flash >pass.ufm
| |
22:00 | Bertl | both should have one line per flash page/row for your device
| |
22:01 | Bertl | hmm, sec, is it a 640 or 640U?
| |
22:03 | John_K | 640HC i believe
| |
22:05 | John_K | # python pic_jtag_id2.py
| |
22:05 | John_K | found MXO2-640HC [00000001001010111001000001000011]
| |
22:05 | John_K | usercode 00000000 [00000000000000000000000000000000]
| |
22:05 | John_K | traceid 00:443307090C5242 [00000000:01000100001100110000011100001001000011000101001001000010]
| |
22:05 | John_K | looks good
| |
22:07 | John_K | which file do I pass first to pic_jtag_prog?
| |
22:07 | Bertl | sec, I think they are wrong
| |
22:07 | John_K | ok
| |
22:10 | Bertl | okay, was a bug in the makefile
| |
22:10 | Bertl | I've update the makefile and the resulting files
| |
22:11 | John_K | any way we can throw these into git?
| |
22:11 | John_K | it's a bit of a pain to sync the website all the time
| |
22:11 | Bertl | I will do that soon
| |
22:11 | John_K | ok
| |
22:11 | John_K | happy to help there as well
| |
22:12 | John_K | so i'll re-download the binaries for the 640
| |
22:12 | Bertl | only the svf.flash is relevant for now
| |
22:12 | Bertl | you process it as explained and get two files
| |
22:12 | Bertl | 1151 1151 37983 pass.cfg
| |
22:13 | Bertl | 192 192 6336 pass.ufm
| |
22:13 | John_K | right
| |
22:13 | John_K | did that
| |
22:13 | Bertl | ./pic_jtag_prog.py pass.cfg pass.ufm
| |
22:13 | Bertl | will flash the FPGA with the config and usermem
| |
22:14 | Bertl | you might need to adjust the feature row after that, but the default should be fine in this case
| |
22:15 | Bertl | you can check the result with pic_jtag_dump.py
| |
22:16 | Bertl | note that you only want to program the RFE (sel B)
| |
22:17 | John_K | ok
| |
22:20 | Bertl | if you just want to test code, you can use the pic_jtag_sram.py (not optimized yet) to upload the data to the SRAM
| |
22:20 | John_K | ok
| |
22:20 | John_K | so this all looks good
| |
22:20 | Bertl | the lattice FPGAs have a surprisingly low rewrite count for their flash (~ 10k)
| |
22:27 | John_K | hrm, if I attach the sensor to the system now, I get a ton of emmc1 spew to the console
| |
22:27 | John_K | mmc1 rather
| |
22:27 | John_K | I seem to remember you saying that's normal and that I should disable it? is that right?
| |
22:28 | John_K | only seems to happen when I attach the sensor though
| |
22:44 | Bertl | interesting, the sensor should have no effect on that
| |
22:45 | John_K | sensor locates in the bottom left of the socket correct?
| |
22:45 | Bertl | top left
| |
22:52 | John_K | # ./cmv_init.sh
| |
22:52 | John_K | 0x0000026F
| |
22:53 | Bertl | \o/
| |
22:53 | Bertl | so now we are right there where we left of two weeks ago :)
| |
22:54 | John_K | hah, yep
| |
22:54 | Bertl | next step is to train the LVDS
| |
22:54 | Bertl | ./cmv_train3 -a
| |
22:55 | Bertl | upload the output to a pastebin please
| |
22:55 | John_K | of course
| |
22:55 | John_K | https://gist.github.com/anonymous/31dac6d8858cd0ea0117
| |
23:01 | Bertl | excellent
| |
23:01 | Bertl | everything seems to be working fine
| |
23:01 | John_K | \o/
| |
23:01 | John_K | does cmv_snap3 have the ability to capture pixels to a file?
| |
23:02 | Bertl | yes, but I would suggest that you now reactivate the startup scripts
| |
23:02 | John_K | ah yes
| |
23:02 | Bertl | or alternatively start them manually
| |
23:03 | Bertl | they will activate live HDMI out (doesn't matter if you have a plugin module inserted or not :)
| |
23:04 | Bertl | and you should be able to check that everything is working with ./cmv_perf3
| |
23:04 | Bertl | (which gives you the frame rates)
| |
23:04 | John_K | trying to figure out what I did when I deactivated the systemd service
| |
23:05 | Bertl | probably just an exit 0, at least that is what I would have suggested :)
| |
23:06 | John_K | I think i removed the file
| |
23:06 | Bertl | /etc/systemd/system/cmv12k.service ?
| |
23:06 | John_K | gone
| |
23:07 | Bertl | bad boy
| |
23:07 | John_K | :P
| |
23:07 | John_K | is it short enough to pastebin?
| |
23:07 | John_K | or should I just re-image?
| |
23:08 | Bertl | http://pastebin.com/raw/d5TNuUpX
| |
23:08 | Bertl | nevertheless double check /root/kick.sh for exit 0 :)
| |
23:10 | John_K | ok rebooting
| |
23:12 | John_K | so what needs to be done manually now that we've re-enabled this?
| |
23:13 | Bertl | not much, try the ./cmv_perf3 on the camera
| |
23:13 | Bertl | it should give you 60FPS HDMI and probably 10-15FPS for the sensor
| |
23:13 | John_K | I don't have HDMI attached
| |
23:14 | Bertl | as I said, doesn't matter
| |
23:14 | John_K | it just prints this and I can't ctrl+c it
| |
23:14 | John_K | # ./cmv_perf3
| |
23:14 | John_K | mapped 0x60000000+0x00400000 to 0x60000000.
| |
23:14 | John_K | mapped 0x80000000+0x00400000 to 0x80000000.
| |
23:14 | Bertl | double check that the kick.sh was activated
| |
23:15 | Bertl | when access to the registers hangs, it is usually because the firmware is missing
| |
23:15 | John_K | yeah I've seen that
| |
23:15 | John_K | how do I tell if kick has run?
| |
23:15 | Bertl | systemctl status cmv12k
| |
23:16 | John_K | hrm
| |
23:16 | John_K | https://gist.github.com/anonymous/503950c537e01c7c7cbd
| |
23:16 | John_K | training doesn't appear to have worked
| |
23:17 | Bertl | get the full logs
| |
23:17 | John_K | zynq is at 86c
| |
23:17 | Bertl | you have some heat sink/fan attached, yes?
| |
23:17 | John_K | not yet
| |
23:17 | Bertl | then I would suggest doing that
| |
23:17 | John_K | of course
| |
23:18 | Bertl | the zynq will go up to 130°C and then reboot :)
| |
23:18 | Bertl | journalctl -u cmv12k
| |
23:20 | John_K | https://gist.github.com/anonymous/dc54c81251e2278c8fe3
| |
23:22 | John_K | looks like the power isn't coming up correctly
| |
23:25 | Bertl | why do you conclude that? power looks fine in the first dump
| |
23:26 | Bertl | but there is no CMV temperature
| |
23:26 | John_K | yes it does, I was looking at the wrong dump
| |
23:26 | Bertl | this might be related to the missing feature bits
| |
23:26 | Bertl | try the following on the RFE
| |
23:27 | Bertl | ./pic_jtag_feat.py 0000000000000000 0620
| |
23:28 | John_K | sec, need to stop kick to do that
| |
23:29 | John_K | https://gist.github.com/anonymous/b8b95c10e08576199965
| |
23:30 | Bertl | okay, try a reboot now
| |
23:32 | John_K | still no dice
| |
23:32 | John_K | bit pattern of 0's
| |
23:32 | John_K | hrm I don't think i re-flashed the PIC
| |
23:33 | Bertl | bad boy, again! :)
| |
23:33 | Bertl | but that is not the problem here
| |
23:33 | Bertl | the problem is that the RFE doesn't come up properly
| |
23:34 | John_K | does the training rely on the RFE?
| |
23:34 | Bertl | it relies on communicating with the sensor
| |
23:34 | Bertl | i.e. on the SPI bus
| |
23:34 | John_K | so the RFE came up when we did it manually
| |
23:34 | Bertl | in your log, the CMV reports 0000 as temp
| |
23:35 | Bertl | 0x0000026F -> 0x00000000
| |
23:37 | Bertl | so, either the FPGA is kept from initializing (because of bad inputs)
| |
23:37 | Bertl | or it was not flashed properly
| |
23:38 | John_K | so I took the latest sfv.flash that you gave and generated new files
| |
23:38 | John_K | [root@beta 640]# openssl sha1 pass.svf.flash
| |
23:38 | John_K | SHA1(pass.svf.flash)= a8a209b81042d3b084deca83940ac06c70f3a1fd
| |
23:39 | Bertl | 4e8c703ecb76d31a500f044932165c0f /tmp/pass.cfg
| |
23:39 | Bertl | ff1188444f287a9e407d47966d91aced /tmp/pass.ufm
| |
23:40 | John_K | mine are diff
| |
23:40 | John_K | one sec, let me regen
| |
23:40 | Bertl | sorry, those are md5
| |
23:41 | John_K | md5's match
| |
23:41 | Bertl | ./icsp_sel.py B
| |
23:41 | Bertl | ./pic_gpio.py
| |
23:43 | John_K | https://gist.github.com/anonymous/131f49c643fd44703a88
| |
23:43 | John_K | wait wrong script
| |
23:43 | John_K | I don't have pic_gpio.py
| |
23:44 | John_K | I should
| |
23:44 | John_K | one sec
| |
23:44 | Bertl | quick, get it :)
| |
23:44 | John_K | I swear I mirrored that
| |
23:47 | John_K | https://gist.github.com/John-K/7272794004b842c0546b
| |
23:48 | Bertl | . ./i2c2.func
| |
23:49 | Bertl | i2c2_set 0x38 0x01
| |
23:49 | Bertl | i2c2_set 0x39 0xFE
| |
23:49 | Bertl | ./pic_gpio.py
| |
23:50 | John_K | https://gist.github.com/John-K/7272794004b842c0546b
| |
23:50 | John_K | appended
| |
23:52 | John_K | only C* values appear to have changed
| |
23:53 | Bertl | yeah, INITN and DONE should go high when the RFE initializes
| |
23:54 | John_K | ah, so RFE isn't initializing correctly
| |
23:54 | Bertl | yes, for whatever reason
| |
23:54 | John_K | shall I dump it?
| |
23:55 | Bertl | yes, please
| |
23:57 | John_K | https://gist.github.com/John-K/1dd8279fcbd263ee9f96
| |
23:57 | John_K | dump script seems to not be 640 aware
| |
23:57 | John_K | looks like its dumping a lot of extra data
| |
23:58 | Bertl | yeah, I got the page count wrong :)
| |
23:59 | John_K | that's just in the dump though I think
| |
23:59 | Bertl | please update mxo2.py
|