| *** tpb <[email protected]> has joined #litex | 00:00 | |
| swetland | aaand TX is happy too. And etherbone is working now. | 00:03 |
|---|---|---|
| jevinskie[m] | :) that is a weird trick. What made you try that?? | 00:04 |
| swetland | well the crc error register ticked up on almost every inbound packet, only a few surviving. made me think the clock was badly aligned | 00:05 |
| swetland | some of the fancier phys have a clock offset parameter but not this one | 00:05 |
| swetland | so by flipping the 0, 1 in the ddrout to 1,0, the clock shifts by half its cycle | 00:05 |
| jevinskie[m] | ah, but of course! nice :) | 00:06 |
| swetland | and it would appear that is sufficient to line up with the rx data reliably (flood pinged the device, dumping rx info in a little test program and it seemed to keep up ok w/ no errors) | 00:06 |
| swetland | big question is, can we parameterize this so I can avoid having local hacky patches -- question for _florent_ I suppose | 00:07 |
| * swetland apologizes in advance for inflicting more workaround for more weirdly broken hardware on people... | 00:07 | |
| swetland | upshot is litex_server/litex_cli is also happily chattering with the board via etherbone | 00:08 |
| swetland | hmm. both these etherbone docs mention FEC for UDP but neither specifies an implementation | 00:18 |
| jevinskie[m] | I haven't seen it implemented/used | 00:48 |
| swetland | I guess most of the time on modern switched ethernet on a local link without heavy congestion the chances of dropped or corrupt packets are pretty low | 01:02 |
| shorne_ | hello, is there still any effort/will to get litex SoC's into qemu? | 01:21 |
| shorne_ | I am working on adding some stuff for openRISC, and thinking maybe also it would not be too hard to get the litex devices in | 01:22 |
| shorne_ | I guess the concern before was that litex soc's could be reconfigured and change and qemu want's their hardware definitions to be static. But I think the board configs are more stable now | 01:25 |
| swetland | shorne_: I've been adding a few peripherals for a RV32 target in qemu. haven't tried pushing them upstream yet | 01:56 |
| swetland | work in progress over here: https://github.com/swetland/qemu/commits/litex | 01:57 |
| swetland | have chatted a bit with _florent_ and mithro about stable CSR/IRQ base addresses. Not sure if there's agreement on exactly how to approach that yet | 01:58 |
| swetland | for now I have a local patch that keeps CSRs on my fpga target from moving around unexpectedly | 01:58 |
| jevinskie[m] | Can’t qemu parse DTS? I wonder if that’s a path forward | 02:14 |
| swetland | ugh. | 02:18 |
| swetland | If you want to pitch that to the Qemu people you'll need to find someone who doesn't hate DTS to do it, which rules me out. ^^ | 02:20 |
| swetland | I gather even trying to get them to agree on "having a runtime configuration language" to set things up has failed multiple times in the past... | 02:21 |
| jevinskie[m] | Oh, that’s disappointing. I come from Apple-dom and as a hobbies Zephyr user so devicetree is natural to me :P | 02:25 |
| swetland | I consider it a really horrific piece of technical debt foisted off on us from open firmware | 02:26 |
| swetland | string matching is error prone and clunky. the data payload typing is basically all by convention, not any actual reliably parsed type indicators, etc, etc | 02:26 |
| swetland | every time I'm forced to deal with it, the results are entire afternoons wasted debugging shit that would have Just Worked if we were still using board files | 02:27 |
| swetland | so, no, not a fan | 02:27 |
| shorne_ | jevinskie[m]: well, qemu can also generate dts, so as long as the qemu target stays the same and the CSRs inside the decive don't move around it should be ok | 02:33 |
| shorne_ | The goal would be able to have a kernel that can boot on both qemu and litex, so we can test litex software/drivers | 02:36 |
| swetland | yeah from the standpoint of "can I run the same kernel on qemu-litex and some-fpga-litex", both can provide you with DTS and then at least as long as the specific registers within a CSR bank don't move around, you should be okay | 02:36 |
| shorne_ | yeah, thats my thought, so the issue of litex changing memory maps is not really an issue with qemu | 02:37 |
| swetland | and I think that's desirable anyway since code is going to upstream linux, zephyr, etc -- needlessly breaking existing drivers by rearranging CSRs within a bank or bits within individual registers feels counterproductive | 02:37 |
| shorne_ | as of now, we have litemmc, liteeth, liteuart upstream in the kernel, so as long as those don't change I think we can build a qemu hw/ | 02:38 |
| shorne_ | yup | 02:38 |
| swetland | mithro has a spreadsheet tracking driver/emulation support: https://docs.google.com/spreadsheets/d/1XTHfdYXuvwoYdPXm4M6qDA0D2fZCPy220-9q6qZpTw4/ | 02:39 |
| tpb | Title: LiteX Soft-CPU, FPGA and Firmware Support - Google Tabellen (at docs.google.com) | 02:39 |
| swetland | now that I'm getting liteeth going on the hardware I'll probably end up doing a qemu implementation of that as well | 02:40 |
| shorne_ | cool, better tick of lite_eth and lite_mmc drivers as upstrea in linux there | 02:41 |
| shorne_ | I thought liteeth was done on the qemu side... | 02:41 |
| shorne_ | https://github.com/timvideos/qemu-litex/blob/master/hw/net/liteeth.c | 02:45 |
| shorne_ | wow from 2018 | 02:46 |
| shorne_ | swetland: ^ thats the liteeth implementation in qemu | 02:46 |
| shorne_ | there are other devices available too | 02:46 |
| swetland | yeah. though it's from 2018 qemu... and 2018 litex | 02:47 |
| swetland | still useful, but probably needs a little adjusting for qemu 7.0.0 | 02:47 |
| shorne_ | thats right | 02:48 |
| *** Degi_ <[email protected]> has joined #litex | 03:47 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 03:47 | |
| *** Degi_ is now known as Degi | 03:47 | |
| shenki | here's a model that will work with the upstream liteeth: https://github.com/legoater/qemu/commit/f22427c91b644bbe3dbcdf1c287ec5ec9c3c63ec | 05:58 |
| shenki | we can submit it i guess. it never went up as we didn't submit the microwatt machine | 05:58 |
| shenki | https://github.com/legoater/qemu/commits/ppc-microwatt | 05:59 |
| shenki | swetland: what's your email address? | 06:12 |
| swetland | [email protected] | 06:20 |
| *** FabM <[email protected]> has joined #litex | 06:59 | |
| shenki | thanks | 06:59 |
| shenki | https://lore.kernel.org/qemu-devel/[email protected]/ | 06:59 |
| tpb | Title: [PATCH] hw/net: Add LiteEth model - Joel Stanley (at lore.kernel.org) | 06:59 |
| shenki | i'm not sure what the qemu reviewers will say about merging a model without a machine that uses it | 06:59 |
| shenki | but at least it's more discoverable on the mailing list than in a random git branch | 07:00 |
| cr1901 | _florent_: Could you answer this when you get the chance? https://libera.irclog.whitequark.org/litex/2022-05-19#32271802; | 07:00 |
| tpb | Title: #litex on 2022-05-19 — irc logs at libera.irclog.whitequark.org (at libera.irclog.whitequark.org) | 07:00 |
| cr1901 | I didn't see it in the scrollback | 07:00 |
| shorne_ | shenki: wow, just got the mail, didn't realize you did a separate implementation, it looks more clean, ill have to review | 07:15 |
| shorne_ | I am working on an openrisc virt board now, it was kind of on my todo for fun projects | 07:16 |
| shorne_ | but as I was doing it I was wondering why we can't do a litex board, now that qemu can jsut generated the DTS for the kernel | 07:17 |
| swetland | I've got a very simple litex machine model I've been using, mostly with the aim of being as close a match to the litex setup I have on a ECP5 fpga board | 07:22 |
| swetland | shenki: thanks for the cc! | 07:22 |
| _florent_ | not really able to contribute, but that's great to see the qemu efforts! Good support would be really nice and would complement the verilator simulations + tests on hardware. | 08:36 |
| _florent_ | cr1901: sorry, forgot to answer, litevideo and opentitan are no longer installed with LiteX no; litevideo can still be used but is no longer maintained (would need to be fully re-written) and for Video Out we now have a simple core directly integrated in LiteX; opentitan was install for ibex, but we switched to the ibex repo directly. | 08:37 |
| swetland | _florent_: opinions on clock skew hackery for liteeth/phy/rmii.py ? | 08:38 |
| swetland | I was getting 90+% crc errors on rx on the muselab board w/ waveshare module | 08:39 |
| swetland | the cheesy trick of swapping 0 and 1 here fixes rx for me: self.specials += DDROutput(0, 1, clock_pads.ref_clk, ClockSignal("eth_tx")) | 08:39 |
| swetland | (all the hardware I try to use with litex appears to be cursed in some way) | 08:39 |
| _florent_ | swetland: lol, hoping we won't have to put workaround everywhere for all the combinations of cursed hardware you are using :) | 08:42 |
| _florent_ | I would need to have a closer look, I never had trouble with the current setting, but I should have a closer look to see if it's optimal or not | 08:44 |
| _florent_ | we could eventually add a parameter to configure the clk phase. | 08:44 |
| swetland | well the good news is I'm running out of Litex peripherals to discover bad interactions with! Though I haven't fully put spiflash and sdcard through their paces yet... | 08:51 |
| swetland | one piece of information: my waveshare board is *not* LAN8720A. It's DP83848 (https://www.ti.com/product/DP83848-EP) | 08:52 |
| _florent_ | swetland: OK, I have to add a LAN8720A RMII module to one project in a couple of days. While doing so, I'll look at the LAN8720A/DP83848 datasheets | 12:10 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 14:36 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:10e1:b51c:4acf:914d> has quit IRC (Read error: Connection reset by peer) | 17:03 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:8db5:5914:188d:d12d> has joined #litex | 17:44 | |
| *** linearcannon <linearcannon!~linear_ca@2600:1700:4090:5fe0:2d1d:4cb2:2dc2:a05f> has joined #litex | 18:38 | |
| *** linear_cannon <linear_cannon!~linear_ca@2600:1700:4090:5fe0:b569:c5ef:a9d6:a48d> has quit IRC (Ping timeout: 248 seconds) | 18:38 | |
| *** linear_cannon <linear_cannon!~linear_ca@2600:1700:4090:5fe0::3d> has joined #litex | 18:54 | |
| *** linearcannon <linearcannon!~linear_ca@2600:1700:4090:5fe0:2d1d:4cb2:2dc2:a05f> has quit IRC (Ping timeout: 260 seconds) | 18:56 | |
| swetland | _florent_: Thanks! I've got a batch of LAN8720A RMII pmods arriving from JLCPCB next week so it'll be interesting to see if they work as-is or need trickery. | 20:58 |
| swetland | Also, I guess I'll want to add a commandline option to select between the waveshare and pmod (different pinouts) https://twitter.com/dnaltews/status/1526225492583403523 | 21:00 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!