<sb0>
whitequark: so, rust-lld doesn't compile (it breaks due to an incompatibility with some msp430 definitions in llvm), lld-7 doesn't support riscv, and lld-8 isn't compatible with the llvm-7 that rustc requires. i ended up using good old binutils...
X-Scale has quit [Read error: Connection reset by peer]
_whitelogger has joined #m-labs
futarisIRCcloud has joined #m-labs
rohitksingh_work has joined #m-labs
<mtrbot-ml_>
[mattermost] <sb10q> @astro why exactly do we need the mozilla overlay for building the stm32 firmware? except for the above linker issue, the embedded rust stuff seems to be working just fine (for riscv) with just this trivial overlay https://git.m-labs.hk/M-Labs/HeavyX/src/branch/master/overlay.nix
<mtrbot-ml_>
[mattermost] <sb10q> and the original nixpkgs rust/cargo/etc. packages
sb0 has quit [Quit: Leaving]
<whitequark>
sb: are you building rustc against rust's llvm fork?
<whitequark>
cr1901: yes, connector pins are (in general, by convention) using the same numbering as the physical schematics
<whitequark>
i believe this is absolutely necessary for larger and less common connectors
<mtrbot-ml_>
[mattermost] <sb10q> whitequark: no, should I?
<whitequark>
sb: in general, yes
<whitequark>
it has some patches on top of upstream llvm, which you are hitting
<whitequark>
or rather their absence
zng has quit [Ping timeout: 248 seconds]
zng has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<plaes>
rjo: any idea how to handle the openocd repo fork?
<plaes>
what worries me is that alphamax (netv2) is already pushing stuff on top of m-labs fork
<mtrbot-ml_>
[mattermost] <sb10q> do you want to try and get it merged?
<plaes>
thruth is that I don't know how to actually handle it
<mtrbot-ml_>
[mattermost] <sb10q> well, that's more of a question for upstream openocd :)
<rjo>
plaes: whitesuqark should push his commit upstream and i should push mine. that's it. what alphamax does is his choice. they way openocd reviews patches it doesn't matter much what branch they are based on (apart from functional dependencies).
<plaes>
ok, cool..
sb0 has joined #m-labs
<rjo>
plaes: i'll try pushing both patches upstream now
<plaes>
\o/
<rjo>
and if you are reasonably confident you did a proper job rebasing then i'll also gladly push that to m-labs/openocd
<rjo>
thanks for the analysis and the rebase!
<plaes>
yeah.. there were 2 or 3 patches that required some "manual" fixing but these had been already fixed upstream
<rjo>
what's with the format-overflow and implicit-fallthrough patches?
<cr1901>
whitequark: Do you think the platform files are more or less stabilized at this point?
<whitequark>
cr1901: to some extent
<cr1901>
I don't want to write a how-to-port blog post while the files are still in flux (nor do I want to add more platforms until then- I ported icebreaker b/c that's what I have on hand right now ;)...)
<whitequark>
cr1901: the only change i can foresee right now is adding back default_clk
<whitequark>
but probably nothing beyond that
<cr1901>
Ack. nextpnr issues notwitstanding, there may also be a reason to bring back default clock (or allow platforms to extend it) for FPGAs w/ internal oscillators (Mach series).
<cr1901>
For tinyfpga A/Mach, I dded a "default_osch_period" class var that normally shadows "default_clk_period" unless you're also using a external clock; both need to be set to the same value if using the internal oscillator.
<cr1901>
I could probably handle this edge case nicer in nmigen
<whitequark>
i think if i reintroduce the automatic generation of a CRG (this isn't quite possible yet, it needs to hook into Fragment.prepare), then it should just call a platform method
<cr1901>
provide a default implemenation (or a mixin) that platforms can call (inherit) from, since the default CRG works in the vast majority of cases?
<_whitenotifier-3>
[nmigen-boards] zignig opened pull request #3: pwm breathing with phase offset - https://git.io/fjzkI
<whitequark>
cr1901: yes
rohitksingh_work has quit [Read error: Connection reset by peer]
<_whitenotifier-3>
[nmigen-boards] whitequark commented on pull request #3: pwm breathing with phase offset - https://git.io/fjzks
<_whitenotifier-3>
[nmigen-boards] zignig commented on pull request #3: pwm breathing with phase offset - https://git.io/fjzkl
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #m-labs
<whitequark>
cr1901: hmm
<whitequark>
are you sure you didn't swap DQ0 and DQ1?
<cr1901>
I swapped the order they were listed in the nmigen file, but I remembered to swap the pins too
futarisIRCcloud has joined #m-labs
<cr1901>
I swapped them for consistency w/ the order they are presented in tinyfpga bx
<whitequark>
nvm, it matches schematic
<whitequark>
I think we should just abstract that
<whitequark>
have a function that returns 1x, 2x and 4x (if available) resources
<whitequark>
*way* too error prone to do it by hand each time
<cr1901>
Would this function also work for say, PMOD spiflash boards? Presumably the reason you can abstract it is because each family hardcodes the pins you use for a single SPI flash
<cr1901>
(but not others)
<whitequark>
I mean, all SPI flashes (that I know of) have the same pinout in the sense that MOSI is always DQ[0]
<whitequark>
so you could do something like SPIFlashResources(0, cs_n="F7", mosi="G6") and so on
<cr1901>
... yea sounds like that'll work. I didn't personally verify 4x spiflash works on icebreaker on nmigen. However, I know from my own testing that it works on omigen, so as long as I copied the pinout properly, there shouldn't be any problems.
m4ssi has quit [Remote host closed the connection]
<whitequark>
and actually they should be called wp_n and hold_n
<whitequark>
not wp and hold
<cr1901>
now's the right time to change that before backwards compat ruins everything
<whitequark>
yeah, there's a lot of these issues...
<whitequark>
they also probably should be reset to 1
<whitequark>
which is gonna be *real* annoying to implement
<whitequark>
or i guess they could be just tristated by default?
<cr1901>
I think that's beyond the scope of what platforms should provide. tristate by default seems reasonable if wp/hold_n are known to be pulled up
<cr1901>
wp_n*
<whitequark>
well the thing is
<whitequark>
if you currently request an spiflash
* cr1901
checks misoc and finds the spiflash core doesn't touch wp and hold at all
<mtrbot-ml_>
[mattermost] <astro> we need the mozilla-overlay for non-stable rustc. I'll have a look at this alternative.
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined #m-labs
<whitequark>
cr1901: ok, yeah, so what i was saying is
<whitequark>
if you request wp in nmigen, it will be added as an output
<whitequark>
and the default for an output is to output a 0
<whitequark>
which will make it write-protected and unresponsive
<cr1901>
Ahhhh
mumptai has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Remote host closed the connection]
gnufan_home has joined #m-labs
d_n|a has quit [Read error: Connection reset by peer]
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjzs1
<mtrbot-ml_>
[mattermost] <astro> I cannot get the compiler-builtins to build with rustc 1.32.0 from nixos 19.03. could we switch stm32 to nixos unstable? then I'd give it another try.
<mtrbot-ml_>
[mattermost] <astro> oh, you can get rust nightly without the mozilla overlay?