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
davidc___ is now known as davidc__
rohitksingh_work has joined #m-labs
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined #m-labs
kmehall has quit [Remote host closed the connection]
kmehall has joined #m-labs
<sb0>
rjo, do you really think it's a good idea to store the urukul scan sync result into the eeprom instead of the device database?
<sb0>
it would work just as well in the ddb afaik, and it's more transparent than the eeprom that is relatively difficult to access
<sb0>
the only thing is the user would have to copy/paste results from the calibration kernel into the ddb
hartytp has joined #m-labs
<rjo>
i think writing to the eeprom is much simpler than having the user run calibrations, edit device databases, compiling startup kernels, flashing them.
<rjo>
the best solution is one that i don't have to interact with.
<sb0>
whether it's in the eeprom or not doesn't change whether this involves startup kernels
<sb0>
also, why the eeprom and not the existing flash storage?
<rjo>
the urukul eeprom seems to be the appropriate place for urukul related calibration data. does the right thing if you swap them. but i don't insist on that. writing the urukul eeprom is literally a handful lines of code.
<sb0>
what about debugging? there is already infrastructure for e.g. accessing the flash storage from the host, but not the eeprom
<rjo>
if the data is in the eeprom and not in the device db, then you don't have to reflash the startup kernel each time the calibration drifts a bit.
<sb0>
drtio can be problematic as well
<sb0>
there's also a cable delay in there, so swapping doesn't always work
<sb0>
if cables have different lengths
<rjo>
i think i2c through drtio needs to land sooner or later anyway.
<rjo>
yes. it won't work in those cases. but that's not an argument against enabling it in the cases where it works.
<rjo>
accessing the eeprom from the host sounds much easier than figuring out and maintaining the mapping of that calibration data space and the various urukuls. also the cli tools might be what you use all the times. but they are rarely used by users. and consequently stuff goes wrong all the time if you force them to use the CLI tools. and the configuration/setup overhead of a system is already large enough. why
<rjo>
add another iteration of generating and copypasting calibration data?
<sb0>
using those eeproms for storing anything other than a hardware ID is redundant with the flash storage
<rjo>
no
<rjo>
is there even a api to access the flash storage from kernels?
<sb0>
there is low-level i2c, which is also supported through drtio
<sb0>
but is that the right interface?
<sb0>
also we may want to support flash storage over drtio to recalibrate saymas
<rjo>
nice. so that might even work over drtio without too much headache then.
<rjo>
i think sayma rtm/amc also have i2c eeproms.
<sb0>
conceptually it is redundant with the flash storage, and this calibration data is something that is linked to a kasli+urukul combination
<sb0>
just like it is linked to a amc+rtm combination
<rjo>
ultimately, if i do calibration of offsets, gain errors, dds amplifier power curves etc, i'd want to store that in the i2c eeprom. then calbiration can be done at the factory and you can move it over.
<sb0>
also for sayma it is handled by firmware, not kernels
<rjo>
you are saying that one storage is generally redundant with another storage?
<rjo>
i think there are important differences between the different storages that we have.
<sb0>
for things that are dependent on the card with the eeprom *only*, like type of hardware, MAC address, offsets, then the eeprom is ok
<sb0>
but the sync timing involves the kasli, the cable and the urukul
<rjo>
the storage seems to be a pretty bad choice for this. the file system is pretty crappy i.e. if you throw all the different kinds of things into it then you'll run into problems with the block becoming full. then you'll need tooling to automate the compression and re-writing.
<rjo>
the eeproms give you a natural hierarchy and can be accessed at the granularity you want.
<sb0>
there is already code for cleaning up a full sector, which is buggy, but should get fixed this week
<sb0>
it's not a complicated fix
<rjo>
i2c isn't complicated either
<sb0>
but the storage needs to be fixed anyway
<rjo>
my guess is that the flash storage will have other problems that will show up when somebody wants to have larger startup and idle kernels.
<rjo>
but we also need the i2c stuff for eem enumeration and ddb generation
<sb0>
fine. keep at that and do not try to use it for writing stuff...
<rjo>
but we need support for writing the eem-local calibration stuff anyway.
<sb0>
speaking of device db autogeneration, there will be a problem to detect if a card is in 1-EEM or 2-EEM mode
<rjo>
why?
<sb0>
ah no, i misread the urukul sch
siruf has quit [Ping timeout: 265 seconds]
siruf has joined #m-labs
siruf has quit [Remote host closed the connection]
siruf has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 268 seconds]
<GitHub181>
[smoltcp] whitequark commented on pull request #244 00a5dc2: This docstring isn't informative at all. What does "registered on cidr" mean? It's not clear from the documentation whether this function would only return a route that is an exact match or any route matching the argument.... https://github.com/m-labs/smoltcp/pull/244#discussion_r206491539
<GitHub99>
[smoltcp] whitequark commented on pull request #244 00a5dc2: The naming of this function is inconsistent with `set_*_default_route`. Either this should be called `set_route`, or those functions should be called `add_*_default_route`. They fundamentally do the same thing. https://github.com/m-labs/smoltcp/pull/244#discussion_r206492153
<GitHub26>
[smoltcp] m-labs-homu commented on issue #186: :umbrella: The latest upstream changes (presumably 1fbcfb09e1b4165a2778d6ab55bbbc462444dfa1) made this pull request unmergeable. Please resolve the merge conflicts. https://github.com/m-labs/smoltcp/pull/186#issuecomment-409191032
<travis-ci>
m-labs/smoltcp#1136 (master - 1fbcfb0 : Astro): The build passed.
<GitHub194>
[smoltcp] jD91mZM2 commented on issue #244: Since you previously said you don't think this is needed, I'll just close this because I'm lazy :stuck_out_tongue:. Better now than later when I put in more time into something that isn't even desired. https://github.com/m-labs/smoltcp/pull/244#issuecomment-409202279
<key2>
am thinking of using 4 of them connected to a FPGA clock shifted in order to get 4GB :) could be a fun open source oscilloscope
<rjo>
sb0: btw. i noticed that xilinx uses the xadc/sysmon to calibrate things (ddr delays in that case). maybe the broken xadc reference pins are a problem for sayma, gth, termination etc as well. but i give it a <20% chance of being an issue (gth/termination using the xadc/sysmon).
<sb0>
key2, let us know what kind of horrid bugs you find in this other HMC critter!
<key2>
sb0: it was just an idea
<key2>
but why wouldn't it be doable ? bc of timing issues ?
X-Scale has quit [Ping timeout: 244 seconds]
[X-Scale] has joined #m-labs
<sb0>
rjo, do you want to write this in the xilinx support email thread?
rohitksingh has quit [Read error: Connection reset by peer]
<sb0>
key2, because HMC chips are trash fires. we have 3 of them on sayma, and 2 are awful.
<key2>
sb0: they all behave the same ?
<key2>
this HMC is the one used in RIGOL scopes
rohitksingh has joined #m-labs
<key2>
so I thought of using 4 of them, a FPGA, DDR3 and usb 3
<key2>
could make a 300$ board with that
<sb0>
key2, the hmc830 has reserved AND WRITE-ONLY registers that don't initialize to their default values, which causes the chip to break intermittently
<sb0>
key2, it also has some idiotic protocol selection that is easy to lock the chip into
<key2>
mmh
<key2>
ok, then let's concider that this HMC has no bug
<key2>
could it be a fun board ?
<key2>
only 8bit tho, but for doing an open source scope..
<sb0>
key2, the HMC7043 has several broken registers, plus in many occasions the doc says one things and ADI people on forums say another, plus it generates broadband noise that causes bugs in other chips when unconfigured
<GitHub11>
[smoltcp] whitequark commented on issue #178: @astro To expedite merging, I've fixed all remaining issues I found. Please review them, and squash the commits once you find the state of the branch satisfactory. I'll merge afterwards. https://github.com/m-labs/smoltcp/pull/178#issuecomment-409256907
<GitHub88>
[smoltcp] robomancer-or commented on pull request #186 0acca35: Not returning anything here means that this code can't be used for other types of host configuration (notably: [PXE](http://www.pix.net/software/pxeboot/archive/pxespec.pdf), for network booting). DHCP is designed to do more than just networking parameters. Is there some reason not to return some representation of the response packet? https://gi
<GitHub108>
[smoltcp] astro commented on pull request #186 35b3314: I have given it a try to return the `DhcpRepr<'a>` but that is really cumbersome as it is bound to the lifetime of the packet received by `raw_socket.recv()` in this function. Check my branch `dhcp-return` if you would like to work on that.... https://github.com/m-labs/smoltcp/pull/186#discussion_r206611232
<GitHub32>
[smoltcp] robomancer-or commented on issue #258: Ah, I see, I forget that some people can use dynamic memory. So it's up to the caller to request exactly as many bytes as their packet is going to end up being... that still seems odd. What about ... https://github.com/m-labs/smoltcp/issues/258#issuecomment-409298463
<GitHub58>
[smoltcp] robomancer-or commented on issue #258: Ah, I see, I forget that some people can use dynamic memory. So it's up to the caller to request exactly as many bytes as their packet is going to end up being... that still seems odd. What about ... https://github.com/m-labs/smoltcp/issues/258#issuecomment-409298463
<GitHub92>
[smoltcp] robomancer-or commented on issue #258: Ah, I see, I forget that some people can use dynamic memory. So it's up to the caller to request exactly as many bytes as their packet is going to end up being... that still seems odd. What about ... https://github.com/m-labs/smoltcp/issues/258#issuecomment-409298463
<GitHub156>
[smoltcp] robomancer-or commented on issue #258: Oh. I didn't realize that. Sorry, the documentation on crates.io is pretty out of date, so I'm trying to work out how to use it all by reading the source, I missed that tidbit. Forget I said anything :-) https://github.com/m-labs/smoltcp/issues/258#issuecomment-409300129
<GitHub35>
[smoltcp] robomancer-or commented on issue #258: Oh. I didn't realize that. Sorry, the documentation on docs.rs is pretty out of date, so I'm trying to work out how to use it all by reading the source, I missed that tidbit. Forget I said anything :-) https://github.com/m-labs/smoltcp/issues/258#issuecomment-409300129
<GitHub161>
[smoltcp] robomancer-or commented on pull request #186 35b3314: Step one I'll get a proof of concept working locally (otherwise my proposal is likely to miss some important details). I'll be back. https://github.com/m-labs/smoltcp/pull/186#discussion_r206616765