11:11 <leons> Is there a way to use litex_sim with a preloaded ram file, but to not autoboot (i.e. still get the shell in bios)?

11:49 <leons> In general, how should I approach debugging with litex_sim best? I have a binary which works on an ArtyA7. The mem regions match up. Even a simple binary loaded using `--mem-init` which just writes a byte to the UART txrx-register (3 basic instructions) doesn't seem to work :/

11:50 <_florent_> leons: you can abort the boot sequence with Q or ESC

11:52 <_florent_> leons: maybe you could look at: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/sim.py, we are using the same binaries for the simulation and hardware

11:53 <_florent_> leons: this one can also be interesting: https://github.com/enjoy-digital/litex_vexriscv_smp/blob/master/sim.py

11:56 <leons> florent: Those are great references, thanks! I tried aborting the boot sequence with Q, but the window is too small. Also, with ethernet enabled, the simulation is just stuck somehow... I'll investigate

11:58 <_florent_> leons: you can just press ESC or Q when you see the LiteX banner, it will also works

13:06 <leons> Okay, weirdly enough everything works just fine as long as a put my binary in the ROM, using `litex_sim.py` with `--ram-init` does not work and I'm still not sure why...

13:08 <leons> Maybe there are some issue with accessing the data in RAM? I've tried using SDRAM like linux-on-litex does, but I don't get past the memcheck, even when I set the bus,data,addr size to 0, as done in the sim.py of linux-on-litex

13:13 <_florent_> leons: i could have a look, so you are just usign litex_sim with --ram-init and aborting the boot to check the ram content?

13:35 <leons> _florent_: That'd be awesome, but you of course don't have to. I'm using `litex_sim.py` from master with `--ram-init` and want to check the RAM content, though I don't manage to abort the boot

13:35 <leons> I suppose I could undefine the `ROM_BOOT_ADDRESS`

13:38 <leons> It appears like the binary is loaded correctly...

13:52 <leons> _florent_: Thanks for your help! I'll definitely continue to look into my issue, but for now I'm incredibly happy that my binary works in ROM!

13:53 <_florent_> leons: not sure to understand, so this is working with --rom-init but not --ram-init?

13:59 <leons> _florent_: exactly. Of course I'm changing the base offsets in my ELF, but that shouldn't even matter as the first three instructions should already output a character on the UART

14:00 <_florent_> leons: ok strange that if works on hardware

14:01 <leons> _florent_: I agree. I'm using pretty much the same binary, so the RAM addresses are the same. Just stripping out some peripherals such as the LED, etc.

14:02 <_florent_> leons: would you mind creating an issue in LiteX for this with the software or binary and steps to reproduce? I'm in a middle of something else so can't help that much now but i could have a closer look later

14:02 <leons> _florent_: sure!

20:35 <leons> _florent_: Would you be open to adding a `--timer-uptime` command line parameter to soc_core.py? I've come to use it quite frequently and would happily create a PR

20:42 <_florent_> leons: yes sure, this can indeed be useful, thanks.

22:07 <acathla> On an iCE40up5k I already have 12MHz and 48MHz for USB (fomu style), I need a 24MHz clock. What's the best way to add it?

22:08 <acathla> I added a self.sync.usb_48 += self.cd_ir_24.clk.eq(~self.cd_ir_24.clk)

22:09 <acathla> But since it's linked to the 48MHz it does not always pass the timing analysis

22:15 <acathla> Or... my design is just a bit too full