#apertus IRC Channel Logs

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

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

by "how you load it" I mean, how you program the svf to the Lattice

morning folks!

aha

it's still dieing before that on the first i2c write

I have to run to the post office to get a package, I'll be back in half an hour or so

but will check channel later

https://gist.github.com/anonymous/2830eecf8ab10f2892a1

err _flash rather

option A or B is valid

B

i2c = SMBus(2)

i2cdetect -r -y -a 2 ?

looks fine

that's all?

if you have the pic programmed, it should show entries in row 10 and 30 as well

(if the mux (70) is steered properly)

i re-programmed the pic to be sure, it programs fine but i2cdetect still returns the same thing

I get things in row 10 and 20

yes

so that bus/pic is working

note that you need to program both pics

does it detect the pic fine as well?

hrm, after I did that, picB now seems to work

./icsp_picid.py A

./icsp_picid.py B

now, anyway

ok I think things are ok now

yep, it wasn't tested yet with anything but a 2000

yes, I added this for the future :)

ah :)

anyway, really have to run now ... bbl

ok, thanks

I'm off to bed, will pick this up in 7 hours or so

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)

Bertl: hi

then start with ./pic_jtag_id2.py

if that identifies and outputs proper info, the other files should work as well

ok, will get things setup and test

you need to use a separate tool to generate svf

unless you're doing it differently somehow

ah, I see, sec

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

okay, just checking ...

sure, no problem

they have some connectivity throughout the main board

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

yep, similar in the dummy interface board, which currently is "just wires"

(and will be replaced by a proper FPGA solution later)

cd /opt/PIC/PIC16/PIC16F1718/

aha thanks

yeah the i2c_slave.c needs to be updated though

wrestling with flexlm on linux

I was using the windows version yesterday, just installed it in my linux machine to use your makefiles

checking to see if I need to install flexlm on its own or something

everything should work with the free license

ok, did you have to start a license server or set an environment variable?

ahh

many thanks

you can be happy that they support 64bit and you don't have to mess with 32bit libraries as well :)

ldd said all of the libraries were present, internet hinted at lsb

&$%& DRM licensing crap

(i.e. evil ascii blob :)

will try spinning up a RedHat VM to see if Lattice crap works in that

was also testing centos in a container (worked as well)

ok I'll try centos

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/640/

0.33

what you do now is the following:

gawk -f svf2cfg.gawk pass.svf.flash >pass.cfg

both should have one line per flash page/row for your device

640HC i believe

found MXO2-640HC [00000001001010111001000001000011]

traceid 00:443307090C5242 [00000000:01000100001100110000011100001001000011000101001001000010]

which file do I pass first to pic_jtag_prog?

ok

I've update the makefile and the resulting files

it's a bit of a pain to sync the website all the time

ok

so i'll re-download the binaries for the 640

you process it as explained and get two files

192 192 6336 pass.ufm

did that

will flash the FPGA with the config and usermem

you can check the result with pic_jtag_dump.py

ok

ok

the lattice FPGAs have a surprisingly low rewrite count for their flash (~ 10k)

mmc1 rather

only seems to happen when I attach the sensor though

sensor locates in the bottom left of the socket correct?

# ./cmv_init.sh

\o/

hah, yep

./cmv_train3 -a

of course

excellent

\o/

yes, but I would suggest that you now reactivate the startup scripts

or alternatively start them manually

and you should be able to check that everything is working with ./cmv_perf3

trying to figure out what I did when I deactivated the systemd service

I think i removed the file

gone

:P

or should I just re-image?

nevertheless double check /root/kick.sh for exit 0 :)

so what needs to be done manually now that we've re-enabled this?

it should give you 60FPS HDMI and probably 10-15FPS for the sensor

as I said, doesn't matter

# ./cmv_perf3

mapped 0x80000000+0x00400000 to 0x80000000.

when access to the registers hangs, it is usually because the firmware is missing

how do I tell if kick has run?

hrm

training doesn't appear to have worked

zynq is at 86c

not yet

of course

journalctl -u cmv12k

looks like the power isn't coming up correctly

but there is no CMV temperature

this might be related to the missing feature bits

./pic_jtag_feat.py 0000000000000000 0620

https://gist.github.com/anonymous/b8b95c10e08576199965

still no dice

hrm I don't think i re-flashed the PIC

but that is not the problem here

does the training rely on the RFE?

i.e. on the SPI bus

in your log, the CMV reports 0000 as temp

so, either the FPGA is kept from initializing (because of bad inputs)

so I took the latest sfv.flash that you gave and generated new files

SHA1(pass.svf.flash)= a8a209b81042d3b084deca83940ac06c70f3a1fd

ff1188444f287a9e407d47966d91aced /tmp/pass.ufm

one sec, let me regen

md5's match

./pic_gpio.py

wait wrong script

I should

quick, get it :)

https://gist.github.com/John-K/7272794004b842c0546b

i2c2_set 0x38 0x01

./pic_gpio.py

appended

yeah, INITN and DONE should go high when the RFE initializes

yes, for whatever reason

yes, please

dump script seems to not be 640 aware

yeah, I got the page count wrong :)

please update mxo2.py