*** tpb has joined #litex | 00:00 | |
*** lf has quit IRC | 00:45 | |
*** lf has joined #litex | 00:46 | |
*** FFY00 has quit IRC | 01:56 | |
*** FFY00 has joined #litex | 01:56 | |
*** FFY00 has quit IRC | 01:58 | |
*** FFY00 has joined #litex | 01:58 | |
*** FFY00 has quit IRC | 02:00 | |
*** FFY00 has joined #litex | 02:04 | |
*** FFY00 has quit IRC | 02:07 | |
*** FFY00 has joined #litex | 02:07 | |
*** FFY00 has quit IRC | 02:09 | |
*** Degi has quit IRC | 02:11 | |
*** FFY00 has joined #litex | 02:12 | |
*** Degi has joined #litex | 02:12 | |
*** FFY00 has quit IRC | 02:12 | |
*** FFY00 has joined #litex | 02:13 | |
*** FFY00 has quit IRC | 02:15 | |
*** FFY00 has joined #litex | 02:16 | |
*** FFY00 has quit IRC | 02:25 | |
*** FFY00 has joined #litex | 02:26 | |
*** FFY00 has quit IRC | 02:38 | |
*** FFY00 has joined #litex | 02:39 | |
*** alanvgreen has quit IRC | 04:19 | |
*** alanvgreen has joined #litex | 04:19 | |
*** felix__ has joined #litex | 08:28 | |
*** felix_ has quit IRC | 08:28 | |
*** felix__ is now known as felix_ | 08:31 | |
*** kgugala_ has joined #litex | 08:37 | |
*** kgugala has quit IRC | 08:38 | |
*** kgugala_ has quit IRC | 08:46 | |
*** kgugala has joined #litex | 08:46 | |
*** Dolu has joined #litex | 09:07 | |
*** lkcl has quit IRC | 09:21 | |
*** lkcl has joined #litex | 09:27 | |
*** TMM has quit IRC | 10:34 | |
*** TMM has joined #litex | 10:34 | |
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:11 |
---|---|---|
*** st-gourichon-fid has quit IRC | 11:18 | |
*** st-gourichon-fid has joined #litex | 11:18 | |
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:49 |
_florent_ | leons: you can abort the boot sequence with Q or ESC | 11:50 |
_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:52 |
_florent_ | leons: this one can also be interesting: https://github.com/enjoy-digital/litex_vexriscv_smp/blob/master/sim.py | 11:53 |
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:56 |
_florent_ | leons: you can just press ESC or Q when you see the LiteX banner, it will also works | 11:58 |
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:06 |
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:08 |
_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:13 |
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:35 |
leons | It appears like the binary is loaded correctly... | 13:38 |
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:52 |
_florent_ | leons: not sure to understand, so this is working with --rom-init but not --ram-init? | 13:53 |
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 | 13:59 |
_florent_ | leons: ok strange that if works on hardware | 14:00 |
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:01 |
_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! | 14:02 |
*** kgugala_ has joined #litex | 14:26 | |
*** kgugala has quit IRC | 14:27 | |
*** kgugala has joined #litex | 14:40 | |
*** kgugala_ has quit IRC | 14:43 | |
*** peeps[zen] has joined #litex | 16:32 | |
*** peepsalot has quit IRC | 16:34 | |
*** peepsalot has joined #litex | 16:52 | |
*** peeps[zen] has quit IRC | 16:53 | |
*** somlo has quit IRC | 17:52 | |
*** somlo has joined #litex | 18:38 | |
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:35 |
_florent_ | leons: yes sure, this can indeed be useful, thanks. | 20:42 |
*** awordnot has quit IRC | 21:32 | |
*** awordnot has joined #litex | 21:58 | |
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:07 |
acathla | I added a self.sync.usb_48 += self.cd_ir_24.clk.eq(~self.cd_ir_24.clk) | 22:08 |
acathla | But since it's linked to the 48MHz it does not always pass the timing analysis | 22:09 |
acathla | Or... my design is just a bit too full | 22:15 |
*** awordnot has quit IRC | 22:53 | |
*** awordnot has joined #litex | 22:54 | |
*** cjearls has quit IRC | 23:00 | |
*** peepsalot has quit IRC | 23:26 | |
*** peepsalot has joined #litex | 23:44 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!