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
f4bug has joined #m-labs
<sb0>
whitequark, nice
f4bug has quit [Quit: Leaving.]
<whitequark>
sb0: wow
<whitequark>
I just discovered that runtime::config worked by sheer accident
<whitequark>
it got overwritten by heap immediately. the only reason it worked is that no one actually initialized heap structures before we read anything from config
<GitHub186>
[smoltcp] dlrobertson opened pull request #107: Ensure ICMPv4 error replies comply with size reqs (master...icmp_size) https://github.com/m-labs/smoltcp/pull/107
<GitHub175>
[smoltcp] whitequark commented on pull request #107 8f21610: No, this is actually not enough, 576 is the minimum datagram size. If you have e.g. an Ethernet header in front, then MTU of 576 is not sufficient. https://github.com/m-labs/smoltcp/pull/107#discussion_r158663760
<GitHub196>
[smoltcp] whitequark commented on pull request #107 8f21610: No, this is actually not minimum MTU, 576 is the minimum datagram size. If you have e.g. an Ethernet header in front, then MTU of 576 is not sufficient. https://github.com/m-labs/smoltcp/pull/107#discussion_r158663760
<GitHub195>
[smoltcp] dlrobertson commented on pull request #107 8f21610: It is the minimum MTU for IPv6 https://tools.ietf.org/html/rfc8200#section-5. I think that is where I got confused. I'll have to think about how to best word this, since it is the minimum datagram size for IPv4 and the minimum MTU for IPv6. Maybe we end up with `IPV4_MIN_DATAGRAM_SIZE` and `IPV6_MIN_MTU`? https://github.com/m-labs/smoltcp/pull/107
<GitHub35>
[smoltcp] whitequark commented on pull request #107 8f21610: Still not quite, it's very confusing. Take a look at https://en.wikipedia.org/wiki/Maximum_transmission_unit#MTUs_for_common_media. The minimum MTU on IPv4 is actually 68, but since we never fragment ourselves, the *effective* minimum MTU supported by smoltcp on IPv4 is 576. This needs to be documented, and the constant can remain the same. https://g
<whitequark>
so, rustc 1.20.0 fails to compile smoltcp in one way, and 1.22.1 compilesit but then it doesn't accept any packet
<whitequark>
wonderful
<whitequark>
justwonderful
<whitequark>
why did I expect anything to work lol
<whitequark>
sb0: here's an idea
<whitequark>
let's have (for ARTIQ at least) the BIOS in rust
<whitequark>
it would use the same config area (so it knows mac and ip), it could use smoltcp (maybe with udp only, but not necessarily), and we could share most of the code
<whitequark>
then, when the runtime crashes, it could reboot into BIOS and you could pull the postmortem or even a core dump from there
<whitequark>
given that we don't have JTAG
<whitequark>
that would be really handy
<sb0>
whitequark, okay, but there are more urgent things to do right now
<whitequark>
sure
<whitequark>
for 3.2 I think we can get away with shipping runtime.elf
<whitequark>
so that I can do symbolization locally
<sb0>
also there are a bunch of somewhat annoying things that will have to be rewritten, e.g. sdram initialization code
<whitequark>
that's another thing I want the Rust BIOS to do, I want the firmware to be an ELF
<whitequark>
then symbolization can be trivial
<whitequark>
and right now it's a pain in the ass because of the linker script
<sb0>
where is runtime.elf going to go in 3.2?
<whitequark>
I'd have to list out all the .debug_* sections, figure out a way to load them, figure out something for symtab/strtab...
<whitequark>
in conda packages.
<sb0>
ok, and then how is a backtrace obtained?
<whitequark>
just so I can cross-reference it with bug reports.
<sb0>
ah, ok
<whitequark>
backtrace is copied in hex form from the console
<whitequark>
and attached to the bug report.
<sb0>
ok
<sb0>
sounds good
<whitequark>
not exactly user friendly but I have looked at alternatives and they all take an awful lot of effort
<sb0>
the C BIOS can go completely, the only problem is the time it will take to rewrite and debug stuff
<whitequark>
what about other misoc targets?
<sb0>
why would they become broken?
<whitequark>
there's the lm32 people
<whitequark>
or what do you mean by "completely"
<sb0>
hm, yes, lm32...
<whitequark>
I would really rather kill all C parts in misoc but lm32.
<whitequark>
bb-m-labs: force build --props=package=rust-core-or1k conda-lin64
<bb-m-labs>
build forced [ETA 44m28s]
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
bb-m-labs: force build --props=package=llvmlite-artiq conda-all
<bb-m-labs>
build #92 forced
<bb-m-labs>
I'll give a shout when the build finishes
<rohitksingh>
readback is now supported due to the true dual port ram module, and acks are now registered
<rohitksingh>
CPU seems to be booting up fine, and wishbone interface is working fine (if I understood its specs rights, and implemented wb_master correctly)
<rohitksingh>
I could test on hardware too once your review of code is done