sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sb00 has joined #m-labs
<sb0> whitequark, what is the difference between tm4c129x-vendor.xml and tm4c129x.xml?
<sb0> and how did you unfuck rustfmt?
<sb0> Rustfmt failed at stdin:23: line exceeded maximum length (maximum: 1000, found: 3920) (sorry)
<GitHub162> [dslite2svd] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/dslite2svd/commit/d527f3febb73eb63db94ff84a580a4ea71d3a23b
<GitHub162> dslite2svd/master d527f3f Sebastien Bourdeauducq: Regenerate with newer svd2rust.
<sb0> whitequark, have you seen this? https://crates.io/crates/aligned
<whitequark> sb0: the aligned crate won't work for us i think
<GitHub65> [ionpak] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/ionpak/compare/8247c8f5a56b...98b17fc57424
<GitHub65> ionpak/master 98b17fc Sebastien Bourdeauducq: update dependencies
<GitHub65> ionpak/master 1da96a2 Sebastien Bourdeauducq: convert ADC interrupt count to milliseconds
<whitequark> because we need higher alignment than any of the builtin types
<whitequark> so you don't have anything to provide as the `ALIGNMENT` argument
<whitequark> also there's an open rust bug for #[repr(align=N)] and I'd rather just use that once it gets fixed
<whitequark> re rustfmt: I'm not sure, I think older urstfmt didn't get mad because of that
<sb0> the solution was to increase max_width in rustfmt.toml
<whitequark> regarding -vendor.xml, *-vendor.xml is exactly what TI provided, converted to svd from dslite
<sb0> I regenerated the files using the files that do not have -vendor
<whitequark> whereas *.xml is *-vendor.xml with the patch applied
<whitequark> the patch fixes some of the bugs in the dslite definitions
<sb0> okay
<whitequark> there is a makefile that works a bit like `quilt` if you've seen that
<whitequark> if you need that, remind me to document the way to use it
<sb0> ah, I had missed the regeneration part of that Makefile
<whitequark> if you're updating dslite2svd, i think it's worth upgrading to the latest cortex-m release, too
<sb0> yeah everything is updated
<sb0> in fact I updated dslite2svd because I wanted to update cortex-m
<whitequark> excellent, thanks
<sb0> crates.io still has the 0.4 crate for the tm4c stuff
<whitequark> oh you can't publish? moment
<whitequark> hang on
<whitequark> which version of svd2rust did you use?
<sb0> 0.11.3
<whitequark> let me see if they merged everything i wanted them to...
<sb0> AFAICT they did, but perhaps I missed something
<sb0> FWIW the ionpak firmware still compiles fine
<whitequark> without changes?
<sb0> with changes
<sb0> i.e. the new interrupt management stuff
<whitequark> ok
rohitksingh has joined #m-labs
<whitequark> ok, seems fine to me
<whitequark> let me add you to crate owners
<whitequark> sb0: do you have a crates.io login?
<sb0> I login with github
<whitequark> sb0: added you to both crates
<whitequark> should add to smoltcp too, sec
<sb0> ah, tm4c123x breaks
<whitequark> done
<sb0> do we care? why do we support tm4c123x?
<whitequark> now that's weird, seems like a bug in svd2rust perhaps
<whitequark> i added tm4c123x because i could, it was zero extra work on top of 129x
<whitequark> don't bother fixing it, if anyone cares i'll fix that later
cr1901 has quit [Ping timeout: 240 seconds]
cr1901 has joined #m-labs
sb0 has quit [Quit: Leaving]
_whitelogger has joined #m-labs
sb0 has joined #m-labs
<sb0> whitequark, gdb is crapping out now
<sb0> support/load.gdb:1: Error in sourced command file:
<sb0> Dwarf Error: Cannot find DIE at 0xb252 referenced from DIE at 0xfcc3
<GitHub33> [ionpak] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/ionpak/commit/68eb1cdbbab3d127957fd226c91b7c477a182179
<GitHub33> ionpak/master 68eb1cd Sebastien Bourdeauducq: start ADC after initialization, to avoid FIFO overflows
rohitksingh has quit [Quit: Leaving.]
_whitelogger has joined #m-labs
<GitHub19> ionpak/master e676cb5 Sebastien Bourdeauducq: work around ADC sample rate snafu
<GitHub19> ionpak/master f156c7c Sebastien Bourdeauducq: print panic messages on UART
<GitHub19> ionpak/master d18712d Sebastien Bourdeauducq: flashed MAC address doesn't work
<GitHub19> [ionpak] sbourdeauducq pushed 4 new commits to master: https://github.com/m-labs/ionpak/compare/68eb1cdbbab3...cccd6e52f6f5
http_GK1wmSU has joined #m-labs
http_GK1wmSU has left #m-labs [#m-labs]
key2 has joined #m-labs
sb0 has quit [Quit: Leaving]
<whitequark> sb00: yes, gdb is crap
<whitequark> this happens
<whitequark> did you hit a smoltcp bug in the tcp code? what did you figure out
sb0 has joined #m-labs
<sb0> whitequark, that was a driver bug. when smoltcp calls transmit() and the driver returns a slice larger than requested, then it panics deep inside smoltcp
<sb0> I don't know if it makes sense to add some assertions to spot this error rapidly, or if there would be too many of this kind anyway
<sb0> the panic is slightly obscure, e.g. it would only happen after a TCP connection, things like ping are not affected
<whitequark> yes, there should be an assertion, sec
<GitHub29> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/v7rAq
<GitHub29> smoltcp/master ca6fa2d whitequark: Assert that the transmit frame returned by driver has right length....
<travis-ci> m-labs/smoltcp#169 (master - ca6fa2d : whitequark): The build passed.
<sb0> also, I don't know if it's the same bug as in artiq or not, but the http connections are slow and generally do not work well
<whitequark> can you capture some traces?
<sb0> capture coming
<sb0> whitequark, mailed
<whitequark> sweet pic
<whitequark> we'll need something like dhcp, right?
<whitequark> eventually
<whitequark> looked at the bug
<whitequark> 80% it's the same as artiq issue
<whitequark> it's exacerbated because of your browser's concurrent requests
<whitequark> how many buffers do you have, one?
<whitequark> I mean, in the phy
<sb0> 2 TX buffers, 3 RX buffers
<whitequark> 3?
<whitequark> why 3?
<sb0> whitequark, not really a good reason
<sb0> it's DMA, and the number of buffers can be changed
<sb0> btw my "refactoring" commit broke the driver completely for an unknown reason, I'm still using the old version right now for my tests (with the txbuffer length fixed)
<sb0> whitequark, so what's the latest about fixing that bug?
Gurty has quit [Ping timeout: 240 seconds]
Gurty has joined #m-labs
mithro has quit [*.net *.split]
mithro has joined #m-labs
key2 has quit [*.net *.split]
key2 has joined #m-labs
tangrs has joined #m-labs