02:08 <SMB784> I have also tried uploading the verilog files described in sqrl_acorn.tcl from ~/litex/litex-boards/litex_boards/targets/build/sqrl_acorn/gateware to vivado. After synthesis & implementation a bitstream is generated, but it is about 5 times larger than the one generated by running sqrl_acorn.py, and the device isn't recognized by the litepcie kernel module

02:10 <SMB784> so basically I'm pretty much stuck. I just want to be able to create a vivado project that I can add my own custom hardware with the existing litepcie and spi so I can interact with it via pcie and load new bitstreams to it via pcie as well

02:10 <SMB784> if this turns out to just be impossible, maybe I'll jsut have to do it in Migen or something

05:50 <SMB784> alright well that was weird, but i got it working.

05:50 <SMB784> If I run the tcl script in vivado, it generates a bin file of the correct size

05:51 <SMB784> however, if I run each command in the tcl script sequentially in vivado, it gives me a bin file that is about 5 times larger, and that ends up not being recognized by the host system.

05:51 <SMB784> anyway at least now I can modify the design in verilog and add my own flavor to it

06:29 <_florent_> smb784: The LitePCIe generator is intended to be used by users wanting to generate the standalone core and do the integration themselves in their traditional flow (ie users that don't necessarily want to use LiteX for the integration).

06:30 <_florent_> smb784: So this is just generating a verilog code, with a template for the constraints that then need to be adapted to the hardware

06:31 <_florent_> smb784: You then have to do apply the IO constraints/timings constraints as you would do for any other integrated core

06:32 <_florent_> smb784: We also provide the targets in LiteX-Boards using the full LiteX flow and that here are doing the full integration (but not using the standalone verilog core)

06:38 <_florent_> somlo_: nice for OpenSBI/Rocket! We are (slowly) converging between the different Linux projects. Having the patch accepted in OpenSBI will also be useful for Linux-on-LiteX-Vexriscv :)

06:55 <sajattack[m]> somlo: Maybe I should give rocket on acorn another try. I was a bit confused with the boot process though. Does it load over uart like linux-vexriscv or no?

07:00 <sajattack[m]> Or is it too big?

07:01 <sajattack[m]> Can't wait for florent's baseboards to come out :P

10:43 <_florent_> sajattack[m]: the boot process should be very similar (or at least it would be easy to have it similar). I'll try to look at the serialboot over PCIe, it should be possible to make it a lot faster.

13:23 <somlo_> _florent_: yeah, should hopefully make the platform-specific bits of vexriscv support smaller and more concise...

13:26 <somlo_> sajattack[m]: kernel + initrd + [opensbi | bbl] is somewhere around 17M; I boot from either sdcard or over ethernet (tftp), but see no reason why it shouldn't also work over serial

13:28 <somlo_> note that so far I only got opensbi working with the `full` (i.e., gateware FPU enabled) variant of Rocket -- that means nexys4ddr, nexys video, genesys2, but not ecp5

13:28 <somlo_> since bbl emulates the FPU, but opensbi does not

14:49 <sajattack[m]> it looks like the last time I tried I had the uart address wrong in the dts

15:05 <sajattack[m]> thanks for looking into that florent

15:49 <leons> On UltraScale+ I'm commonly getting setup time violations on the idelayctrl reset line, caused by Vivado trying to make up for hold time. What's weird is that it lists this violation under the async_default path group, but it's not really async: it's from the pll4x_clk to the pll4x_clk. Also, the RST pin of the IDELAYCTRL is an asynchronous reset with a minimum pulse width which we meet through the reset_counter in USPIDELAYCTRL, so setup and hold time

15:49 <leons> really shouldn't matter on that path at all

15:50 <leons> I've worked around this by inserting a false path constraint between the ic_reset signals and the IDELAYCTRL, but that looks like a hack. Anyone have an idea on what could be causing Vivado to view these paths as to be violating timing?

16:06 <sajattack[m]> <sajattack[m]> "it looks like the last time I..." <- do I gave the base uart csr or the xover?

17:16 <sajattack[m]> oh shit I got it

17:16 <sajattack[m]> answer: base uart csr

18:28 <mithro> openpowerwtf: Hi!

18:29 <openpowerwtf> hey..it works!

18:30 <mithro> openpowerwtf: What is going on in https://git.openpower.foundation/cores/a2p/src/branch/master/build/litex/litex-1099/master/a2p_cmod7_uarts.py#L112 with your CSRDirectory thing?

18:30 <tpb> Title: cores/a2p: An experimental small core based on VexRiscv, written in Scala - build/litex/litex-1099/master/a2p_cmod7_uarts.py at master - a2p - OpenPOWER Foundation Git System (at git.openpower.foundation)

18:33 <openpowerwtf> that is an experiment, after i was defeated by uarts. i was trying to build a csr array which is a list of all csr addresses and types; i.e. an indirect method to know what was built into gateware

18:33 <mithro> openpowerwtf: Do you have a simple example where you are struggling with two uart instances?

18:33 <openpowerwtf> yes i can comment that out. i don't think it matters.

18:33 <mithro> openpowerwtf: You can't loop over the csrs in the __init__

18:34 <openpowerwtf> i was hoping i could access self.csr before the finalization and set all my reset values. but i see that some csr's aren't in the list at that time.

18:35 <mithro> I'm not sure you mean by "set all my reset values"?

18:38 <openpowerwtf> the directory entries are csr addresses and type field. so they would be initialized with the final csr layout. software would read them to figure out where things like i2c, uart, etc. are based. since i don't think csr locs can be assigned.

18:38 <openpowerwtf> i am not relying on that right now; just messing around

18:40 <mithro> As far as I can see, you will want to do that in `do_finalize`

18:40 <mithro> openpowerwtf: And it would probably be better to just do that in the DTS?

18:41 <mithro> openpowerwtf: If you are able to create a simple example which shows what you are trying to do with multiple uarts then we can help figure out what is going wrong

18:43 <openpowerwtf> ok i will do that one again. i just want to add a uart just like i add i2cmaster, gpio, etc.

18:44 <mithro> openpowerwtf: Yeap, which should be easy and just work -- so I would like to see what you are doing that fails

18:45 <openpowerwtf> should it be a master? seems like not

18:49 <mithro> @openpowerwtf - Just create a simple SoC like https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/tinyfpga_bx.py#L29 and then add extra uarts?

19:10 <openpowerwtf> https://git.openpower.foundation/cores/a2p/src/branch/master/build/litex/litex-1099/simple

19:10 <tpb> Title: cores/a2p: An experimental small core based on VexRiscv, written in Scala - a2p - OpenPOWER Foundation Git System (at git.openpower.foundation)

19:10 <openpowerwtf> similar behavior: INFO:SoCCSRHandler:uart_1 CSR allocated at Location 0. but it doesn't show in csr.csv.

19:15 <mithro> openpowerwtf: This is what I was expecting you to share - https://gist.github.com/mithro/d6069c51a0dc6733f06a2bf2b4a014e8

19:21 <mithro> As far as I can see, UARTBone and UARTPHY don't actually have any CSRs?

19:24 <mithro> openpowerwtf: What does https://gist.github.com/mithro/d6069c51a0dc6733f06a2bf2b4a014e8#file-gistfile1-txt-L110-L113 give you?

19:41 <openpowerwtf> i think neither did as desired. doesn't the second one need the stream to connect it to wishbone?

19:43 <mithro> openpowerwtf: I think you are confusing a "UART" with a "UART to wishbone" bridge

19:44 <openpowerwtf> the second one says SOCCSRHandler allocated both, at locs 0 and 1. but csr_register,ctrl is at fff00800

19:46 <mithro> openpowerwtf: I can't run the script here at the moment, can you paste the complete output of that file I shared?

19:55 <openpowerwtf> yes. but i just noticed that one died because reset address not in defined region. i will try to fix that...

20:03 <openpowerwtf> ok, i added rom at @0. and now there's a uart_1_phy and uart_1 is at fff00800. so maybe i was just missing the add_csr() for the phy. i will go back and try again.

20:31 <mithro> If you didn't have `with_dynamic_baudrate` then you wouldn't see anything under `uart_1_phy`CSRs

20:36 <sajattack[m]> <somlo_> "note that so far I only got..." <- building full4d for acorn at the moment, looks like it's only 50% utilization

20:36 <sajattack[m]> should I send you some bins?

20:42 <sajattack[m]> or maybe I made a mistake

20:52 <somlo_> sajattack[m]: I don't have an acorn, so I wouldn't know what to do with any blobs you might send, sorry; (but great if there's enough room on it!)

20:56 <sajattack[m]> stick 'em here? https://github.com/litex-hub/linux-on-litex-rocket/issues/1

21:24 <_florent_> openpowerwtf: are you trying to add a second UART core or a UARTBone core (UARTBone = UART PHY + Bridge to control the SoC from litex_server)?

21:26 <sajattack[m]> do you have instructions for sbi somewhere?

21:28 <_florent_> https://github.com/litex-hub/linux-on-litex-vexriscv#generating-the-opensbi-binary-optional

21:28 <_florent_> it will also probably work on somlo_'s branch

21:38 <sajattack[m]> ok thanks, and then do I just flash fw_jump.bin instead of boot.bin or does one get created with part of the other?