<GitHub153>
[artiq] sbourdeauducq commented on issue #852: Looks like a hardware bug that we also see here. Make sure that the RTM is installed (there is a MMC firmware bug that intermittently causes this issue if the RTM is not there) and power-cycle the board. Cc @gkasprow https://github.com/m-labs/artiq/issues/852#issuecomment-345904525
<sb0>
<FelixVi> ok, there was some brackets missing in sdram.c << in your code or the original?
<FelixVi2>
that was in my code... the original is fine
<FelixVi2>
I got the memory controller passing memtest again on the second board - but something is wrong. This is super low speed and it feels harder then it should be
<sb0>
misoc/software/memtest needs an additional core
<FelixVi2>
I think this is fixable with extra timing constraints, but migen doesn't support many yet
<sb0>
get it to work without that additional core first. memtest does high bandwidth tests that are more stringent than the simple tests in the bios.
<FelixVi2>
that's something I can look at
<FelixVi2>
yeah, I compiled a simple puts program for testing
<FelixVi2>
flterm doesn't like to let me upload anything (yet)
<cr1901_modern>
FelixVi2: I have a cygwin environment set up. I'll test w/ minispartan6 tomorrow
<cr1901_modern>
won't solve your SDRAM problems, but I can at least figure out whether the whole flow works (incl flterm)
<sb0>
_florent_, did you look into sayma ethernet?
_whitelogger has joined #m-labs
<rohitksingh_work>
sb0: Hi! I haven't yet started work on that (you might be aware of the reason which I had shared via mail). I will be able to work on that starting December, which is coming closer by day! I will finish up my paperworks by then. In my estimate, the core work will not take more than a week by any chance. Getting it merge-able might take time due to review process, since it will be my first contribution (coding and documentation guidelines, review
<FelixVi2>
cr1901_modern: awesome, let me know if I can do anything. My misoc fork has some notes on installation in case you find that useful
<FelixVi2>
cr1901_modern: I think I have an idea what's going on with the memory. But I need to be able to run code to really work on it
<FelixVi2>
cr1901_modern: One can either use timing constraints to improve margin or change the clock tree
<FelixVi2>
cr1901_modern: is that something that applies to lattice fpgas?
<FelixVi2>
either way, probably time to rest for a bit soon, getting this up and running has been a big push
<FelixVi2>
cr1901_modern: I'll hit the bed for now - just pushed to github again so you can see the latest changes - everything on there currently works in my hands (apart from flterm)
<FelixVi2>
thanks again for helping out! I'm off but will check logs again in the morning
FelixVi2 has quit []
<sb0>
_florent_, it's for artix7 with IBUFDS_GTE2
balrog has quit [Ping timeout: 240 seconds]
balrog has joined #m-labs
_rht has joined #m-labs
<sb0>
FelixVi, flterm.c is written for linux, i don't know if cygwin provides the required support
<GitHub96>
[artiq] sbourdeauducq commented on issue #852: I suppose this also works with OpenOCD and most JTAG cables with the ARM pinout, but I have not tried (there is a risk of bricking the board and of more MMC frustration). In ionpak there is an example OpenOCD script to program a ELF binary into a TM4C MCU. https://github.com/m-labs/artiq/issues/852#issuecomment-345980013
<FelixVi>
cr1901_modern: I'm on it again - testing DDR timing again after modification yesterday night (I am back on the first board that liked different timing yesterday)
<FelixVi>
after that, I'll look at flterm again to see if I can get that worked out either for Win or Cygwin
_rht has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Quit: Leaving.]
<FelixVi>
cr1901_modern: I think the problem is that asyncserial.py doesn't wait until there's data coming back from the device
<FelixVi>
sb0: did asyncserial work in Windows at some point? There is code that's win specific but I wonder if it ever got tested
<sb0>
yes, it does
<FelixVi>
sb0: there is one commit that says "Windows compatibility with more pyserial versions"
<FelixVi>
let me try that one, maybe it got broken after
<cr1901_modern>
sb0: Yes I did. I think I should delete and resubmit when ready
<cr1901_modern>
(it was an accident of course)
<GitHub1>
[artiq] jbqubit commented on issue #852: I've switched to using a bench top power supply, no back plane. All power LEDS on Sayma_AMC are illuminated. Current draw on +12V is 363 mA. A new variety of flashing errors appear.... https://github.com/m-labs/artiq/issues/852#issuecomment-346115155
<FelixVi>
and it should wait for the first valid character
<cr1901_modern>
FelixVi: I need you to make a file of all the problems you've encountered (that still exist) for the Cygwin python and native python >>
<cr1901_modern>
while you were compiling a SoC
<cr1901_modern>
B/c I can't keep track of them anymore
<FelixVi>
I wrote it down in the readme of my misoc repo
<cr1901_modern>
And I want _both_. Native python fixes and cygwin python fixes should be separate PRs
<FelixVi>
oh, not to get cygwin started, but for flterm.py
<FelixVi>
i'll get on that
<cr1901_modern>
include the flterm.py issues in this document
<cr1901_modern>
(for both native and cygwin fixes)
<cr1901_modern>
One external dep I would've like to get rid of in misoc is the need for make; a native windows user is unlikely to have that installed
<cr1901_modern>
but I guess failing that, I should just package that as part of the lm32-elf-gcc zip for Windoze
<FelixVi>
My plan was to do monthly builds
<FelixVi>
maybe every three months actually :)
<FelixVi>
But the good news is that I'm finally up and running!!!
<cr1901_modern>
Excellent. As soon as I have gcc built, I'll try on my end
<FelixVi>
cr1901_modern: any idea why busy loops don't seem to work, but inline asm with 'nop' does on lm32?
<cr1901_modern>
does the inline asm have "volatile" qualifier?
<FelixVi>
yeah
<FelixVi>
so it's an optimization thing?
<cr1901_modern>
yes
<FelixVi>
k, that makes sense
<FelixVi>
so I confirm that everything seems good then
<FelixVi>
man, that was a crazy ride to get to this point
<cr1901_modern>
it tells the compiler "anything reachable by the compiler from that specific point can be altered by the asm block"
<cr1901_modern>
(which of course is a lie, but the compiler can't/doesn't look inside asm blocks)
<FelixVi>
I don't remember tbh, but I think busy loops used to work on AVR micros
<FelixVi>
but it's been a while, so I am not sure anymore
<cr1901_modern>
Probably did lol
<cr1901_modern>
FelixVi: So, are you doing everything from the native python now?
<cr1901_modern>
running misoc/migen and flterm?
<FelixVi>
cr1901_modern: misoc/migen in Cygwin, flterm native
<cr1901_modern>
Okay that's still not ideal... should be one or the other. Try my lm32 toolchain w/ the native python
<FelixVi>
yeah, I'll take a look
<cr1901_modern>
_florent_: So, I didn't intend for this to happen, but perhaps sometime soon LiteX should pull in migen/misoc changes?
<cr1901_modern>
B/c right now they're kinda diverging w/ the platforms, style fixes I added, the windoze bug fixes, and platform API changes that rjo wants
<FelixVi>
cr1901_modern: Cygwin tells me resource temporarily unavailable
<cr1901_modern>
I'll check on my machine. Still waiting for gcc
stekern has joined #m-labs
<FelixVi>
cr1901_modern: I think "os != 'nt'" in asyncserial doesn't cover Cygwin
<FelixVi>
resource unavailable seems to be related to non-blocking calls in Cygwin which may be handled differently than *nix
<cr1901_modern>
Different gcc version- Not the same issue
<cr1901_modern>
And you should probably _put_ the error you receive when compiling libquadmath
<FelixVi>
I think it just wan't around when lm32-elf got put together
<FelixVi>
and I doublt we'll need 128-bit fp math on lm32
<cr1901_modern>
I still would like the error anyway
<FelixVi>
I'll make sure to catch the error message when I compile next time
<FelixVi>
actually, why are you using an older version?
<cr1901_modern>
To match the version I have installed
<cr1901_modern>
already*
<cr1901_modern>
just in case
<FelixVi>
I hope we don't get another load of errors from having different gcc versions
<FelixVi>
I just went for the latest one as I hope it has more bugfixes than new problems :)
<cr1901_modern>
FelixVi: In any case, I run into a separate issue "No such file or directory: 'cmd': 'cmd'"
<cr1901_modern>
erm...
<GitHub67>
[artiq] gkasprow commented on issue #852: @jbqubit did you modify the loading script? @jordens posted some time ago that to make JTAG over USB running, one needs to setup right clock edge. https://github.com/m-labs/artiq/issues/852#issuecomment-346151755
<FelixVi>
cr1901_modern: did you add packages as I noted down in the readme?
<FelixVi>
cr1901_modern: It looks like you're missing something
<cr1901_modern>
FelixVi: Will do. Need to take a break for now
<FelixVi>
I also cleaned up my misoc fork to have clean history - hopefully you can see from there what I did
<FelixVi>
sb0: Is there a predefined way if all I want to do is build a software package?
<FelixVi>
I can add it to the target, but would prefer to leave that alone
<FelixVi>
Hmm, but I see how it needs information about the SoC gateware... I guess I'll go through the target
<cr1901_modern>
Okay, break over/dinner eaten. Back to work (for some value of work)
<FelixVi>
Cool, I'm trying to figure out why the linker doesn't find log10 - but can switch to whatever you want to look at
<whitequark>
rjo: o/
<cr1901_modern>
FelixVi: My install was fine. My problem is that I pruned my path a _little_ too much
<cr1901_modern>
including C:\Windows\SYSTEM32
<cr1901_modern>
FelixVi: You said you also had issues with bitstreams or not?
<FelixVi>
cr1901_modern: no, everything is working fine
<cr1901_modern>
I said bitstreams, I meant flash proxy
<FelixVi>
yeah
<FelixVi>
what board are you using?
<cr1901_modern>
minispartan6
<cr1901_modern>
that board is supported in openocd
<cr1901_modern>
xs3cprog does _not_ work with proxy bitstreams last I checked
<cr1901_modern>
at least, not the ones provided by rjo's repo
<FelixVi>
I am not sure, I made my own for the boards I am using
<FelixVi>
I'm looking
<cr1901_modern>
FelixVi: Strictly speaking I didn't need to change anything in misoc to get a successful compile, so I'm not opening a PR for _misoc_ cygwin fixes
<FelixVi>
that's alright
<FelixVi>
I generated my bscan files from xc3sprog/bscan_spi
<cr1901_modern>
and what about native Windows w/ migen/misoc flow?
<FelixVi>
how do you let it know about the compiler location?
<cr1901_modern>
append to cygwin's or windows path
<FelixVi>
turns out I don't have my windows python setup :)
<FelixVi>
ValueError: Cannot extract CSR name from code, need to specify.
<FelixVi>
on python 3.5.2
<FelixVi>
so the path for python 3.6 breaks 3.5
<FelixVi>
that's good to know
<FelixVi>
i get that without the patch, too
<cr1901_modern>
Why won't the bugs stopped? Migen has _never_ been this uncooperative.
<cr1901_modern>
How can you possibly get that without the patch?! Try another virtualenv then
<FelixVi>
hold on
<FelixVi>
I think I got it
<FelixVi>
ah, it doesn't work for the lack of make
<FelixVi>
I forgot the patch for python version was in migen, not misoc
<cr1901_modern>
FelixVi: Right, you need to provide your own make on the path. I wish this wasn't a requirement, but
<cr1901_modern>
haven't thought of a better solution likely to be accepted
<FelixVi>
yeah, that might be a good argument for cygwin
<cr1901_modern>
Still please test it
<FelixVi>
as you can easily compile gcc and binutils and you get make for free
<FelixVi>
I am not sure how to get make
<cr1901_modern>
I'll "lend" you mine, and put it on the same path as the native lm32-gcc
<FelixVi>
is there a build somewhere or do you cross compile?
<FelixVi>
make (e=2): The system cannot find the file specified.
<FelixVi>
make: *** [bios.elf] Error 2
<FelixVi>
i am editing the bios makefile
<cr1901_modern>
I would suggest creating a dummy bat file for chmod. It's a noop on Windows
<cr1901_modern>
(instead of editing the bios makefile)
mumptai has joined #m-labs
<FelixVi>
ok, python3 in common.mak needs to either python or one need another bat file for that
<FelixVi>
at least with virtualenv in windows
<cr1901_modern>
I don't know what that means
<FelixVi>
but the rest seems to be ok
<FelixVi>
python3 doesn't exist, virtualenv lets you choose your python environment to work with and the executable is always python
<FelixVi>
but that's a simple fix
<cr1901_modern>
That's beyond the scope of misoc imho
<FelixVi>
yes and no
<FelixVi>
imho if people can't get misoc to work b/c of problems like this, it's a problem
<cr1901_modern>
Then open a bug
<FelixVi>
at least I don't want to have people come here all the time b/c of a simple issue like that ;)
<FelixVi>
i'll put it in my branch and can submit a PR
<FelixVi>
but need to check whether common.mak is outogenerated or supplied as is
<cr1901_modern>
as-is
<cr1901_modern>
You need to split your fork into features, not submit it all at once
<FelixVi>
I'll clean up submit history before I submit a PR
<cr1901_modern>
edits to common.mak directly are unlikely to be accepted (I mean, _I_ use an edited common.mak for the outdated compile options, but I haven't sent that upstream)
<FelixVi>
but what I am thinking is that I'll have a win branch and a cygwin branch for a while until upstream supports both and my fork can disappear
<cr1901_modern>
that's fine
<FelixVi>
yeah, or it'll stick around b/c it works for my particular situation
<FelixVi>
but I'm happy to submit anything we worked out the past couple days and people can pick what they like
<FelixVi>
it seems to run fine on win - let me test
<cr1901_modern>
I am out of bandwidth right now to fix Windows issues. I lost most of my day to this ._.
<FelixVi>
I think I can handle cleaning things up
<FelixVi>
most issues are worked out, I am now getting a compiler error for one of my software packages
mumptai has quit [Remote host closed the connection]
<FelixVi>
no idea where that is coming from, it doesn't happen in the latest compiler