01:17 <sajattack[m]> what address do I give prog.flash for acorn_cle_215?

02:10 <sajattack[m]> _florent_: getting these errors from vivado after your latest changes to sqrl https://hatebin.com/deosmobfzn

02:10 <tpb> Title: hatebin (at hatebin.com)

09:57 <sajattack[m]> this seems bad https://hatebin.com/bgqvncwjur

09:57 <tpb> Title: hatebin (at hatebin.com)

10:44 <sajattack[m]> this seems better `[ 3283.454953] litepcie 0000:01:00.0: Version LiteX SoC on Acorn CLE-101/215(+) 2021-03-28 03:07:37`

10:45 <sajattack[m]> I think the trick was live reloading, since I can't get persistent flash to work, previously the bitstream was getting corrupted when the system rebooted

10:49 <sajattack[m]> dma test still says 0 gbps

10:49 <sajattack[m]> hm

10:51 <sajattack[m]> scratch test works

12:13 <sajattack[m]> are the dma and wishbone endpoints not included by default?

13:18 <sajattack[m]> if anyone has a fully loaded litepcie config for acorn cle-215+ I'd appreciate it

13:19 <sajattack[m]> barebones is great for building upon, but not great for testing if things are working

16:28 <_florent_> sajattack[m]: One DMA channel (both TX and RX) is included in the default PCIe config. I also tested it on the bitstream I provided.

16:32 <_florent_> The issue could be specific to your config (Linux and/or hardware), for info I was testing on Ubuntu 18.04 with a Intel machine.

16:33 <_florent_> Also I remember we had to update the DMA buffer allocation on a recent Linux kernel for a client and I'm not sure the changes have been integrated in LitePCIe.

16:35 <_florent_> The issue was very similar: MMAP working (Registers) but DMA was crashing the machine, but we were seeing the error with dmesg

17:16 <Melkhior> _florent_ Couldn't get ethernet to work in Linux (it was netbooting alright), but as the micro-sd card works, I've tried a sdcard root, worked fine...

17:16 <Melkhior> So i decided to up the ante a bit, and now I have booted a yocto 'core-image-full-cmdline' on a quad-core RV32GCBK (RV32IMAFDC + bitmanip & crypto) :-)

17:16 <Melkhior> Only apparent problem is a '(agetty)' process eating up a core and the kernel complaining about it in dmesg; it's owned by hvc0 so I'm guessing xen-related stuff I need to get rid off

17:22 <leons> Melkhior: how did you get LiteEth to work? did netboot always work or did you have to do something there (since I have the same issue)

17:23 <Melkhior> I didn't do much beyond fixing the definition for my board so that it auto-detected properly as GMII_MII ; as far as I can tell it then fall-back to MII mode (fast ethernet) in the BIOS and that mostly works - sometimes I've had netbooting failed weirdly... (usually displaying a larger/smaller file downloaded that it should have)

17:24 <Melkhior> auto-selection of MII is done because the sys-clk is < 125 MHz (I'm running at 80 MHz)

17:24 <Melkhior> I tried a 125 MHz stripped-down core & buildroot, but it didn't netboot (sd-card worked perfectly)

17:25 <leons> Melkhior: I see, thanks. I'm running at 200MHz, so sadly that's probably a different problem then

17:25 <leons> You didn't add any constraint regarding the tx clock manually, so it's correctly generated by the rx clock?

17:25 <Melkhior> Myabe linux is using GbE instead of FE for me

17:25 <Melkhior> yes, as far as I can tell for MII

17:26 <leons> okay, thanks. I'll keep digging then. :)

17:26 <Melkhior> if your interface can do MII instead of GMII, you might want to force the mode to be auto-detected as MII

17:26 <Melkhior> (or do a run at 100 MHz)

17:27 <Melkhior> https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/gmii_mii.py#L170

17:28 <Melkhior> force at 1 to get MII

17:28 <Melkhior> _if_ you have a GMII_MII interface

17:28 <Melkhior> don't know if there's something similar for the RGMII interface

17:37 <leons> Makes sense, thanks. For my application I actually must use 1000Base-T, so that's unfortunate :)

17:38 <leons> It seems to work when I manually add a constraint for the tx clock, but I'm pretty sure that's not how it's supposed to work, given that phase offsets between the clocks probably have to be enforced

17:39 <leons> And the fact that only some NICs like it only fosters my suspicion there. :)

17:44 <Melkhior> does it work only in the BIOS or in Linux as well ?

18:25 <Melkhior> @leons with the extra clock constraints I mean

20:51 <leons> Melkhior: sorry, haven't checked yet, going to tomorrow. I don't use Linux, but another embedded OS on there. I don't however see how that should matter, given that all access (also from the BIOS) AFAIK go through the standard CSR interface?