07:05 <_florent_> tnt: tick being 32-bit is indeed clearly a refactoring typo, I just fixed it. But even with this, it indeed seems the UART TX has trouble meeting timing on the iCEBreaker, that's also probably related to the refactoring and easy to fix but I'll wait to have access to my iCEBreaker tomorrow to look at it.

07:17 <tnt> _florent_: I fixed the typo here locally already but indeed still an issue. I temporarely set the phase to 16 bit to make it work here in the meantime.

07:18 <tnt> However when looking in detail at the path, it seems nextpnr is doing weird things with that carry chain and doesn't keep it where it should leading to lots of unnecessary delays. gatecat said they would take a look at it.

07:19 <tnt> because a 33b adder should be fine and meet timing.

07:19 <tnt> Something else I'd recommend for the up5k example btw is to switch to the minimal variant of the vex by default. The fomu example for instance is like 120% full by default ...

10:43 <tnt> What are the example supposed to do btw ? I see the banner printed on serial https://pastebin.com/n2irUZtg but I thought there was a command prompt ?

10:43 <tpb> Title: __ _ __ _ __ / / (_) /____ | |/_/ / /__/ / __/ - - Pastebin.com (at pastebin.com)

10:54 <cr1901> Looks like it's crashing. I've seen this before, but I forget the solution :/

10:55 <cr1901> tnt: If you repeatedly reset the example (I think pushbutton should work), does the character at which the BIOS dies changes?

10:56 <tnt> cr1901: No, always the same.

10:57 <cr1901> I wonder if the UART FIFO is getting in a state where the transmitter thinks it's empty, but the CPU thinks it's full

11:00 <cr1901> https://github.com/enjoy-digital/litex/issues/779 icebreaker uses FTDI, so the linked issue won't be equivalent, but I do wonder if it's another "UART FIFO sync" issue

11:03 <tnt> Don't think so. I tried adding a printf at the beginning of crcbios() and I see that. But I don't see the BIOS CRC passed / BIOS CRC failed.

11:31 <tnt> seems to crash at any printf that's not "constant". (i.e. not optimized to a puts() )

11:31 <tnt> So something is definitely very wrong somewhere.

11:39 <geertu> tnt: Yes, there's something strange going on with printf(). Perhaps stack corruption?

11:40 <tnt> geertu: mmm, interesting theory. I'm not even sure where litex puts the stack tbh.

11:42 <tnt> Ah so, I removed the kwargs["cpu_variant"] = 'minimal' which I had added to use a smaller vex and now it goes further. It does get to the prompt. I can't _type_ anything, it just seems frozen there though.

12:10 <tnt> Where is the linker script that gets used ?

12:10 <tnt> There are "parts" in the build/ directory ./include/generated/{regions,output_format}.ld but that's obviously not complete and I can't find the rest.

12:36 <_florent_> tnt: https://github.com/enjoy-digital/litex/commit/d6f24f2f68285b72d9345b5d25cb4cf56da3c87c should fix the timing issue

12:38 <_florent_> Otherwise, for the BIOS issue, it could be that you compiled it for the standard variant and then build the minimal, just be sure to do a rm -rf build before

12:38 <_florent_> But Jedrzeg also saw an issue with VexRiscv minimal recently: https://github.com/enjoy-digital/litex/issues/937

12:39 <_florent_> not sure it was related to a dirty build directory, or if VexRiscv minimal is really broken

12:39 <_florent_> On the iCEBreaker, serv is also a nice option: --cpu-type=serv

12:44 <tnt> _florent_: trying that patch now.

12:44 <tnt> _florent_: SERV is very slow however ... I want to get a base system up so I can try to add a litex wrapper for my usb core so I'd like a decent speed to run the stack.

12:50 <tnt> _florent_: ok, so that patch definitely improved things. Doesn't meet timing ( 20 vs 24 ) but at least it's much better and I expect that to run fine.

12:51 <tnt> And seems like rm -Rf helped too, now the bios has a working prompt both with the default and the minimal variant.

12:52 <tnt> Thanks !

12:52 <gatecat> _florent_: what do you think about litex storing the cpu&variant in a text file in the software dir and automatically deleting all object files if it has changed?

12:53 <gatecat> this bug has bitten me before, also seen very weird and hard to debug linker failures when moving between a 32bit core and and 64bit core

12:53 <gatecat> again because of the software dir being out of date

13:04 <tnt> What got me is that it seems to rebuild "some" things when even just doing --flash so I thought it reubuilt the whole sw but I guess not everything.

13:19 <_florent_> gatecat: We should definitely do something yes, I just created https://github.com/enjoy-digital/litex/issues/950 and will work on it next week

13:19 <gatecat> thanks!

14:27 <tnt> Ouch ... ice40 pll support in litex is minimal.

15:04 <tnt> Is `self.bus.add_slave("usb", self.usb.bus, SoCRegion(size=16*kB, cached=False))` ? The correct way to connect an IO peripheral ?

19:29 <tnt> \o/ Got the core wrapped properly (well ... AFAIK) and enumerating

19:30 <tnt> (ok, well I may have claimed victory a bit early ... it enumerates but something is obviously wrong)

19:41 <tnt> No ... I think the cpu is just so slow executing from flash that it was causing the OS to timout when probing the MSC disc.

19:50 <tnt> Now something I could use help with is how to best package it. That's basically the source : https://pastebin.com/pUVPZ3wA

19:50 <tpb> Title: class NitroUSB(Module): def __init__(self, platform, pads, width=32, evt_ - Pastebin.com (at pastebin.com)

19:51 <tnt> Obviously the hardcoded `no2usb_path = ` gotta go. Another issue is that right now I need to manually copy a bram init file into the build dir before the build so that yosys finds it.

19:51 <tnt> I didn't really see an equivalent to 'add_source' to get litex to be able to generate and copy a data file at the right spot.

19:54 <nickoe> tnt: what are you doing? (I have not read the complete backlog)

19:59 <tnt> I was wrapping my usb device core to make it usable in LiteX SoCs.