07:17 <dkozel> Has anyone generated a "big little" type arrangement using LiteX and different RISCV cores?

10:15 <pepijndevos> Is it possible to use SDRAM as sram?

10:19 <pepijndevos> The Icebreaker puts the bios in spiflash, but uses Up5kSPRAM as sram.

10:20 <pepijndevos> On Gowin there is blockram and SDRAM (which is not working yet), so it has to have at least 4k bram as sram to make the bios happy it seems.

10:22 <daveshah> In general, no, as the SRAM is used by the BIOS to do the SDRAM init/test

10:23 <daveshah> Once stuff is booted, then the SDRAM is used as main RAM for whatever you are running

10:23 <pepijndevos> alright, keeping some bram around then I guess.

10:24 <daveshah> In theory you could probably do a very minimal SDRAM init with almost no SRAM

10:24 <daveshah> And then run the rest of the BIOS using SDRAM as RAM

10:24 <daveshah> But it would be hard to debug if things went wrong

10:24 <pepijndevos> If I do 2k it complains the .bss doesn't fit.

10:25 <pepijndevos> Or you mean full custom bios

10:25 <daveshah> That said, is the SDRAM in this case HyperRAM?

10:25 <pepijndevos> no

10:25 <pepijndevos> Or... I think no...

10:26 <pepijndevos> The GW1NR-9 comes with either PSRAM which is indeed HyperRAM, and the other variant which I have, is just normal SDRAM I think.

10:26 <daveshah> It might be possible to use that SRAM, I don't know how the LiteX hyperram stuff works

10:26 <daveshah> I think I'm getting confused with the variants

10:48 <pepijndevos> huuuuh... yea it's totally not liking vexriscv. picorv32 and serv boot the bios just fine, but vexrisc gets stuck after the ascii art and copyright and never gets to the prompt

10:48 <pepijndevos> how can i debug that?

11:48 <_florent_> pepijndevos: are you using a specific variant of Vexriscv? can you try with adding self.add_constant("UART_POLLING") to your design?

11:49 <pepijndevos> To the SoC class?

11:49 <_florent_> yes

11:53 <_florent_> pepijndevos: btw i just received some TEC0117 boards :)

11:53 <pepijndevos> woohoo

11:55 <pepijndevos> _florent_, still same... only the header, no bios prompt

11:59 <_florent_> pepijndevos: what are the specific changes? can you share the design to have a look?

12:00 <pepijndevos> I guess I'll submit the PR I have so far for the platform/target stuff.

12:00 <pepijndevos> Progress on the SDRAM is basically: Gowin only gives you encrypted IP, no docs on the actual SDRAM

12:08 <pepijndevos> https://github.com/litex-hub/litex-boards/pull/110

12:08 <tpb> Title: Add initial support for Trenz TEC0117 board by pepijndevos · Pull Request #110 · litex-hub/litex-boards · GitHub (at github.com)

12:51 <pepijndevos> huh... it's stuck at 0% on uploading the kernel. This worked before...

12:52 <pepijndevos> [LXTERM] Uploading litex-example.bin to 0x40000000 (1440 bytes)...

12:52 <pepijndevos> |> | 0%

12:57 <daveshah> might be worth trying the minimal/lite variants of vexriscv to see if there is a difference

12:58 <daveshah> also, check with another platform just to rule out environment issues

12:59 <pepijndevos> This upload issue is now actually the same for serv and picorv32 (I can't try for vexriscv because the bios is not functional)

13:07 <pepijndevos> sram is just completely broken or something... or not mapped where I think it is.

13:08 <pepijndevos> It tries to write to 0x40000000 but that just reads as 0xffffffff

13:08 <pepijndevos> writes seem to get ignored

13:15 <pepijndevos> yes so... mem_map says sram is at 0x1000000

13:16 <pepijndevos> It's trying to write to main_ram, but I don't have any of that... huh??

13:26 <pepijndevos> okay so if I pass --kernel-adr 0x1000000 that should be where sram is, but still stuck...

13:36 <pepijndevos> I'm confused... I reverted to simple.py and it's happily uploading to 0x40000000 despite not having any memory there to my knowledge.

13:48 <pepijndevos> Yea so... on simple.py it happily writes into a void at 0x40000000. With mem_read/write it's always ff no matter what.

13:49 <pepijndevos> I'm not even clear how this is *supposed* to work under normal circumstances. Because overwriting the bios at 0x0100000 is of probably also slightly problematic...

13:51 <pepijndevos> on simple.py writing to 0x01000000 goes to 12% until presumable it overwrites some data the bios was using.

16:35 <tcal> I'm trying to use `wishbone-tool -s gdb` over an ethernet bridge, with etherbone on the SoC. With a full+debug VexRiscv CPU. Most things work, but breakpoints don't. That is, I can set a breakpoint to somewhere in my code and then `continue` in gdb, but then the program running on the SoC goes through the breakpoint without stopping. Is this expected, or am I doing something wrong?

18:23 <tcal> Ok, I got some hints from kgugala. I looked at the VexRiscv DebugPlugin, and by default it's built with 0 breakpoints, and that's how it's built in my SoC. So I could try changing that. But I'm also trying to coerce GDB to use a software breakpoint. Although then I might need to figure out how to flush the ICache so that the CPU gets the modified instruction.

19:02 <somlo> _florent_: one of today's litedram and/or litex commits causes memtest to fail on my nexys4ddr (only tried with Rocket)

19:03 <somlo> I have to be afk for a few hours, but will try to get more specific about it later (e.g., bisect) unless you beat me to it :)

19:05 <somlo> meanwhile, here's a screenshot: https://imgur.com/a/7LAGKMC

19:05 <tpb> Title: Imgur: The magic of the Internet (at imgur.com)

22:33 <kbeckmann> _florent_: i tested the colorlight with ethernet today and was thinking if we could solve the timing issues by using the DDR2X primitives. has this been looked in to at already or are patches welcome here?

22:33 <kbeckmann> i checked the pads used and this should be fine - left and right side are used.

23:42 <somlo> _florent_: it's a PITA to `git bisect` across two repos, litex and litedram, but here's two fairly recent (as of this morning) commits that still worked: litex 6f136f9f, and litedram c4d7083