<mtrbot-ml>
[mattermost] <sb10q> davidc: working on it. In a few weeks you can drag and drop cards into a crate and get a price estimate. This will be on the m-labs.HK website
<mtrbot-ml>
[mattermost] <hartytp> @davidc__ oom is 1k eur/usd
<mtrbot-ml>
[mattermost] <hartytp> The pricing from ts is a bit stochastic at present
<mtrbot-ml>
[mattermost] <sb10q> @dpn there is certainly a way as it is used in some places (e.g. with a "nix build" - and not "nix-build" - command) but I do not know how to activate it
<mtrbot-ml>
[mattermost] <sb10q> @dpn we are supposed to have 300Mbps upload here
<davidc__>
hartytp: thanks! It won't work for my possible application then, so I'm glad I didn't bother people for a formal quote! :)
<mtrbot-ml>
[mattermost] <sb10q> just tried from my laptop, I get 7MB/s
<mtrbot-ml>
[mattermost] <sb10q> over wifi, which is probably the limiting factor
<mtrbot-ml>
[mattermost] <dpn> This might actually be a very uncharacteristic problem on our network
<mtrbot-ml>
[mattermost] <sb10q> (and over internet but still within HK)
<mtrbot-ml>
[mattermost] <hartytp> @davidc__ I think it’s just not produced in the volume to get the price down to be competitive with some other eval boards
<mtrbot-ml>
[mattermost] <dpn> Okay, getting > 4 MB/s from GitHub (i.e. S3 – the download I tried finished before the throughput stopped going up) and 200-400 KB/s from nixbld.m-labs.hk.
<davidc__>
hartytp: That's totally fair; and about what I expected. Its overkill for my use case, but if the pricing was right, no reason not to use it!
<mtrbot-ml>
[mattermost] <dpn> (There seems to be some weird network issue on the other host I was actually running nix on.)
<mtrbot-ml>
[mattermost] <sb10q> davidc: what's your application?
<davidc__>
Some custom test & measurement stuff, not quantum mech/physics related
<mtrbot-ml>
[mattermost] <sb10q> with ARTIQ?
<davidc__>
sb10q: I'd probably reuse some of the ARTIQ gateware if I went down that route, but likely not the entire framework. I haven't really thought it out - was just a potential option I was considering
<mtrbot-ml>
[mattermost] <sb10q> ok. if you're ok with reduced FPGA speed/area it would be interesting to run it on ECP5 with the open toolchain
proteusguy has quit [Ping timeout: 265 seconds]
_whitelogger has joined #m-labs
<davidc__>
sb10q - is an ECP5-based board in the works?
proteusguy has joined #m-labs
<Astro-_>
thank you for the zc706 reset, it's working now
<mtrbot-ml>
[mattermost] <sb10q> no. for physics, the speed is already an issue on artix7 as present...
<mtrbot-ml>
[mattermost] <sb10q> @astro what's the idea behind the StaticAllocator?
harryho has joined #m-labs
proteusguy has quit [Ping timeout: 268 seconds]
proteusguy has joined #m-labs
<harryho>
Astro-_: You're welcome! I learnt something too.
<cr1901_modern>
Astro-_: Took me two weeks, but I finally checked out the Ethernet repo and I'll spend some time looking at it tonight/tomorrow for F7 support :P
<mtrbot-ml>
[mattermost] <sb10q> F7?
<cr1901_modern>
sb10q: I only have an STM32F7 nucleo on hand, and F7's ethernet driver looks similar enough to F4 that it's prob worth porting
<cr1901_modern>
rather than buying another board I don't really need
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
attie has joined #m-labs
attie has quit [Ping timeout: 246 seconds]
sb0 has joined #m-labs
<sb0>
whitequark: is there a plan to support IOB registers in nmigen?
<sb0>
whitequark: iirc you were ok with removal of artiq_devtool, right? much of it is bitrotten/superseded (no more conda for firmware compilation, ipv6, different board locks, different sayma variants, etc)
<whitequark>
sb0: they are already supported properly
<whitequark>
sure, you can remove artiq_devtool
<sb0>
btw it sounds simple enough to implement ipv6 ipsec authentication headers on the device
<sb0>
dealing with it in the router isn't
<sb0>
unless the linux kernel is patched or similar extreme measures are taken, the only part of ipsec where the router can deal with encryption is tunnel mode - and then it's just another VPN which encapsulates *whole* packets...
<sb0>
AH is just another packet header with a HMAC of the rest of the packet
<sb0>
on the linux side it can be added with "ip xfrm" without obscure behavior, unlike other parts of the xfrm api which seem to be intended only for the internal consumption of freeswan & co, with a lot of quirks
<whitequark>
sure, adding support for AH doesn't look unreasonable
<_whitenotifier>
[nmigen] whitequark opened issue #263: On Xilinx platforms, IOB should be set on the cell, not the net - https://git.io/JezTR
<_whitenotifier>
[smoltcp] MabezDev synchronize pull request #313: Add capactity methods to packet_buffer & raw sockets - https://git.io/Jeu7s
<key2>
then with ip xfrm set the encryption and sig scheme, with keys
<sb0>
okay. AH or ESP?
<sb0>
I got AH to work like this, but couldn't get ESP to work. the sender would encrypt the packets, but the recipient would simply ignore them with no error logged anywhere
<sb0>
it seems *swan uses a bunch of weird undocumented options that might prevent this issue from occuring
<Astro-_>
@sb10q one-time allocation to slice and zero a portion for ethernet dma
jfng has joined #m-labs
<sb0>
Astro-_: eventually I think the bootloader will initialize the DDR and then load the whole firmware there, and then we can use the regular allocators
Stormwind_mobile has quit [Ping timeout: 245 seconds]
attie has quit [Ping timeout: 252 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
Stormwind_mobile has joined #m-labs
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 240 seconds]
Stormwind_mobile has quit [Ping timeout: 240 seconds]
X-Scale has joined #m-labs
X-Scale` has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
Stormwind_mobile has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #m-labs
<mtrbot-ml>
[mattermost] <pathfinder49> @astro Are the build instructions for thermostat still up to date? Following the instructions on Ubuntu with a new rustup install gives this error: https://pastebin.com/VtzHVSt1
Stormwind_mobile has quit [Ping timeout: 265 seconds]
<mtrbot-ml>
[mattermost] <sb10q> @pathfinder49 update smoltcp, downgrade rust, or switch to nix which always gives you the same rust version
Stormwind_mobile has joined #m-labs
<mtrbot-ml>
[mattermost] <hartytp> @astro at some point can you migrate thermostat to a more recent version of smoltcp than the ancient one on crates.io?
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
mumptai has joined #m-labs
attie has quit [Ping timeout: 246 seconds]
lkcl has joined #m-labs
<Astro-_>
whitequark: did you notice, the person who opened the last PRs on smoltcp is the one who created the rust-esp fork
<Astro-_>
I haven't managed to package it in nix :(
Stormwind_mobile has quit [Ping timeout: 276 seconds]
Stormwind_mobile has joined #m-labs
<Astro-_>
@sb0 alloc, sure.
rohitksingh has quit [Ping timeout: 264 seconds]
Stormwind_mobile has quit [Ping timeout: 268 seconds]
<Astro-_>
@pathfinder49 thermostat-ionpak repo now updated to current rust + smoltcp
proteus-guy has quit [Ping timeout: 268 seconds]
Stormwind_mobile has joined #m-labs
Stormwind_mobile has quit [Remote host closed the connection]
<mtrbot-ml>
[mattermost] <dpn> @pathfinder49: I saw a note about not upgrading Rust on the floor that looked like it had fallen off from the dungeon PC monitor – I guess that was related to this? Switching between concurrently installed toolchain versions should be easy using rustup.
<mtrbot-ml>
[mattermost] <hartytp> @dpn how do you install/switch to a particular revsion (git rev) of rustc?
<mtrbot-ml>
[mattermost] <hartytp> I assume there is an easy way, but didn't find it after a few minutes on google
<mtrbot-ml>
[mattermost] <hartytp> @astro as a general point, it would be great to keep as much overlap (both in terms of code structure and tooling) as possible between thermostat and stabilizer once we move to the STM32 version of thermostat
<mtrbot-ml>
[mattermost] <dpn> @hartytp: `rustup default nightly-2019-10-28` works (i.e. use dates, not git hash – I'm not sure whether all individual CI builds are retained)
<mtrbot-ml>
[mattermost] <hartytp> Yes that’s roughly what I tried, may be that the version I wanted was cleared
<Astro-_>
if that works well, I'd add it to the README