00:46 <somlo> daveshah: bisect says it's yosys commit #ca99b1ee (which makes no sense to me, as it's just changes in how/when error logging happens)

08:00 <daveshah> somlo: my guess then is it is some general instability in the DDR3 interface that depends on PnR seed

08:12 <_florent_> somlo: can you post the logs of the DDR3 calibration for both non-working/working cases?

10:32 <somlo> daveshah: although it's too correlated (older yosys ok, newer yosys not ok) which means I likely screwed up the bisect, so I'll try that again just to be sure :)

10:33 <somlo> _florent_: stand by, it'll take me about 45 minutes to get to where my trellisboard is physically located, then I'll post some logs...

11:07 <somlo> _florent_: the read leveling output is identical for both bitstreams (the one generated with the older yosys, which works, and the newer one, where the kernel crashes during early boot)

11:08 <_florent_> somlo: ok thanks

11:08 <_florent_> and the memtest is also passing?

11:09 <somlo> memtest passes, tftp finishes downloading the BBL-wrapped kernel, BBL actually jumps into the kernel, which then hangs after printing out a few lines

11:09 <_florent_> it could be interesting to increase MEMTEST_DATA_SIZE: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/sdram.c#L762

11:09 <tpb> Title: litex/sdram.c at master · enjoy-digital/litex · GitHub (at github.com)

11:11 <_florent_> somlo: can you try to use crc command to do a crc of the kernel image for example in both case?

11:12 <_florent_> just to see if you are able to read the same data from DDR3 in both cases

11:12 <somlo> not sure how to interrupt it after tftp completes, before it starts BBL

11:12 <somlo> I mean, I can probably hack the bios, but is there a more straightforward way ? :)

13:46 <_florent_> somlo: sorry for the delay, you'll probably need to hack the bios yes

19:38 <somlo> _florent_, daveshah: yosys 6464dc3 causes nextpnr to spend HOURS routing litex+rocket on the trellisboard

19:39 <somlo> still at it, since earlier this morning -- figured I'd do the larger MEMTEST_DATA_SIZE before getting back to bisecting between earlier commit boundaries

19:40 <daveshah> I don't think that commit touches anything related to ECP5

19:40 <daveshah> Sounds more like a bad seed, tbh

19:40 <somlo> guess I need to go do family things now, so I'll let it route a bit longer before I kill it and get back to finding the earlier bit of trouble :)

19:41 <somlo> daveshah: it's not the commit itself, but probably whatever else is inbetween it and the earlier one I tried successfully (well, successfully *completed*, with the kernel hanging after bbl)

19:45 <somlo> in maybe related news, those recent ecp5 commits appear to get utilization back below 98% on the versa (didn't test if it actually worked, but it looks like it fits now)

19:45 <daveshah> Yes, I did test that it at least got to memtest

19:45 <daveshah> Utilisation with the packer changes will be around 95%

19:46 <somlo> anyway, gotta go do family stuff now lest I get yelled at, then I'll get back to that bisect I botched yesterday :)

22:14 <somlo> _florent_, daveshah: yosys #6464dc3, trellis #6464dc3, and nextpnr #6464dc3 (latest as of 24 hours ago) -- memtest passes (with the larger MEMTEST_DATA_SIZE), linux kernel hangs after only a few garbled printk's

22:14 <somlo> back to bisect now :)