trabucayre changed the topic of #openFPGALoader to: Universal utility for programming FPGA / Github: https://github.com/trabucayre/openFPGALoader/ Logs: https://libera.irclog.whitequark.org/openFPGALoader
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #openFPGALoader
<trabucayre> Yes I have this one
<trabucayre> I hate proprietary tools: my license is, once again, expired !
<cr1901> I've run into a snag impl'ing UFM writes... they don't seem to be honored :/
<trabucayre> with openFPGALoader?
<cr1901> correct... I can send you my patch if you want
<cr1901> (erase is working)
<cr1901> Yea, I got nothing... this should be working
<trabucayre> yep send me patch :)
<cr1901> Well I did find one mistake at least, so lemme fix that first
<cr1901> trabucayre: Okay I got it working
<cr1901> operands are sent LSByte first (as well as LSbit, which JTAG mandates)
<cr1901> And it looks like the vast majority of the "Operands" that Lattice mandates before "Write Data" can be ignored (or aren't sent over the JTAG interface)
<trabucayre> fuck: jed isn't produces when using edalize
<cr1901> trabucayre: Are you using my repo?
<cr1901> Oh I forgot to commit that
<cr1901> trabucayre: Please pull, I added a script that makes edalize create a JED file
<trabucayre> In fact I have modified edalize to add this line :)
<trabucayre> but it (diamond) complains about missing init.mem
<cr1901> Lemme upload one for you :D
<trabucayre> repo contains this file :)
<cr1901> Yea, what's supposed to happen is that init.mem gets copied to the root of the work directory
<trabucayre> but seems required to copy this to build/xxx directory
<trabucayre> yep
<cr1901> yea, that's _supposed_ to happen automatically (copyto in the .core file)
<trabucayre> it's an interesting use case for a fusesoc fix :)
<cr1901> Mind opening an issue when you get the chance (not immediately)
<cr1901> Oh and do you have the UART enabled on the XO2EVN board (solder jumpers at R14 and R15)?
<trabucayre> mem fileset is never referenced
<trabucayre> yep
<trabucayre> It's the second thing done with this board :)
<trabucayre> (first was openFPGALoader support :) )
<cr1901> Yea I haven't updated the insns to say "yea, for the love of God enable the UART"
<cr1901> trabucayre: Making PR now, please do not merge. There seems to be a minor issue where the first serial msg transmitted after the UFM is programmed is garbled (after the board goes back to loading/running the bitstream). I need to look into this.
<cr1901> http://gopher.wdj-consulting.com:70/paste/init.mem This is an alternate memory file I've been using for testing. Try swapping the two init.mems and programming the bitstream from my repo :D
<trabucayre> There is a trick with EBR & UFM no ?
<trabucayre> seen
<trabucayre> night :)
<cr1901> trabucayre: The bug isn't with my PR... my POR timer isn't high enough for the demo design. Approx 3ms after por is released, openFPGALoader will reset the design again, which confuses the UART transmitter that's in progress transmitting :).
<cr1901> (When openFPGALoader is loading a design, it pulls uart TX low. I think that's a side effect of how most things in MachXO2 are low-by-default, so not much I can do about this
<trabucayre> My jed contains an UFM area with only 0 :(
<cr1901> trabucayre: That's a bug I fixed locally, take the quotes off "data/init.mem" in the .core file's mem fileset
<trabucayre> ok!
<trabucayre> but I not in the good computer... So try it tomorrow
<cr1901> edalize adds a layer of quotes, and Lattice treats ""data/init.mem"" very weirdly
<trabucayre> But issue with UART is weird: openFPGALoader don't use interfaceB
<cr1901> no worries, I'm just letting you know that "yes, I've seen that behavior already :P"
<cr1901> When openFPGALoader is loading a design, MachXO2* pulls uart TX low
<trabucayre> I have to check FT2232 configuration
<trabucayre> sometime It's difficult to understand lattice choice :(
<cr1901> No argument from me there
<cr1901> http://gopher.wdj-consulting.com:70/store/KingstVIS_WSD72EqvVg.png Here's a JTAG trace of ".openFPGALoader.exe -b machXO2EVN C:/path/to/jed"
<trabucayre> eval board have the second interface configured as a fifo. I have spent a couple of hour to find why my UART didn't work at FT2232 level.
<cr1901> I had to turn on "enable VCP" on Windows
<cr1901> I don't know what setup is required on *nix
<cr1901> I figured it "just works" on *nix, since FTDI is quite a bit less silly on *nix
<trabucayre> FT2232 is configured using an eeprom: if interface is configured as a FIFO you have a problem :)
<trabucayre> (with minicom/picocom/kermit/screen)
<cr1901> lol
<cr1901> ahh the msg is so serious, it stops litex for 2 seconds :)
<trabucayre> don't remember if its for machXO2 or XO3 but I have a wire to use FT2232 oscillator as FPGA ref :)
<cr1901> And I see the "problem": ISC_DISABLE seems to automatically also send a REFRESH command. But openFPGALoader then manually sends a REFRESH command after waiting
<cr1901> Maybe I'll look deeper into it later, but I'm not sure it bothers me enough to fix
<cr1901> I saved the trace and, well, the chat's logged :)
<trabucayre> It's true: both are not required: refresh or isc_disable
<trabucayre> TN1204 p49
<trabucayre> a check for all lattice device is required :(
<cr1901> I think you mean page 59, but yes
<cr1901> If my ADHD permits, I'll finalize the UFM PR
<trabucayre> ine
<trabucayre> fine
<trabucayre> my keyboard start to fails...
<cr1901> no worries, I know that feeling
<trabucayre> it's 49 for TN1204 revision 3.9 (2017)
<trabucayre> (yes I have to download latest release - and check if something disapear :) )
<cr1901> Haha, fair enough; FPGA-TN-02155-4.5 is an alternate version of that TN it seems
<trabucayre> and this time ISC_DISABLE is followed by REFRESH :)
<trabucayre> grumph
<cr1901> Of course :'D...
<cr1901> I have a logic error... fixing before asking you to review and merge
<trabucayre> make sense :)
<trabucayre> and here it's 0h30am -> not a good idea to review something :)
<cr1901> And I fixed it... I'll push soon, and you can review whenever. It'll be ready :D
<trabucayre> and checking if ISC_DISABLE or REFRESH are both required for machXO2, machXO3(D)
<cr1901> You're going by the manual... AFAIC it's Lattice's fault for not documenting it may be redundant. I'm just explaining my observed behavior on my own board/JTAG traces :P
<cr1901> (I.e. my _own_ JTAG traces suggests ISC_DISABLE is enough. But I'm not bothered by a UART glitch enough to do anything about it
<trabucayre> lattice.cpp was initially written for machX03: maybe it's required/maybe not.
<trabucayre> just to verify I have to generate svf
<trabucayre> (or using wireshark)
<cr1901> I haven't checked if SVF works for EFB; IME SVF is slooooooooooooooow
<trabucayre> not to use but to read :)
<cr1901> ahhh
<cr1901> Anyways, fixed pushed... my PR is ready
<trabucayre> lattice programmer is slow, svf is awfully slow too :)
<trabucayre> LGTM, just a small nitpick: rest of code use if (xxx) {
<trabucayre> } else {
<cr1901> Oh in getUFMStartPageFromJEDEC?
<trabucayre> yep
<cr1901> fixed
<trabucayre> Applied :)
<cr1901> yay!
<trabucayre> Now: sleep time :)