12:30 <Bk42> hi everybody

12:32 <Bk42> i use picorv32 in lattice fpga and when i try to enable IRQ my project bloks

12:32 <Bk42> without irq enabled i print some string for control

12:33 <Bk42> if i enable irq i don't see nothing on termina

12:33 <Bk42> terminal*

12:33 <Bk42> some suggest?

12:34 <Bk42> i need to enable irq for may project

12:34 <Bk42> my*

12:54 <zyp> are you sure you're not getting stuck in an interrupt handler or something?

12:55 <Bk42> probably yes, but i used native code inside picorv32 equipped on litex

12:56 <zyp> I'm not familiar with the picorv32, but in general a common reason things is hanging when you enable interrupts is because you're not clearing the interrupt properly, so as soon as you return from the handler it fires again, keeping it from running normal code

12:57 <zyp> usually either that or something about the handler is wrong and trigging a fault

12:57 <daveshah> It's also worth being aware that picorv32 interrupts are non-standard

12:57 <zyp> normally I'd recommend checking with a debugger what state it's ending up in, but I'm not sure picorv32 has a debugger interface?

12:58 <Bk42> in fact there is a irq external function that must print a simple string

12:58 <Bk42> but i don't see nothing

12:58 <Bk42> terminal is completely blocked

13:01 <Bk42> i think that there isn't a debugger interface

16:01 <somlo> _florent_: is there a good way to host pre-built binary images anywhere under litex-hub? I'd rather not make them part of the repo itself (I don't want them tracked by git), but it'd be a nice touch to link them from the mythical README.md :)

16:03 <somlo> worst case I can link to my personal web space on www.contrib.andrew.cmu.edu, but that feels somewhat amateurish

16:03 <daveshah> somlo: github releases?

16:03 <_florent_> somlo: I find github issues convenient for that, I just switch pre-built images for linux-on-litex-vexriscv to github issues yesterday to avoid having the linux-on-litex-vexrisv-prebuilt directory

16:03 <_florent_> https://github.com/litex-hub/linux-on-litex-vexriscv/issues/164

16:04 <_florent_> somlo: just upload the file to the issue and it will be hosted there

16:04 <somlo> daveshah, _florent_: thanks, I'll check out both, see what makes the most sense

16:05 <somlo> _florent_ -- and I assume you can link to the binary blob from the git-tracked repository (specifically, the .md readme file)

16:06 <_florent_> somlo: yes

16:06 <somlo> _florent_: how do you deal with updating the binary blobs -- create a new issue, update the existing one? I'll RTFM, but hopefully you can overwrite a binary blob with a newer version, as part of the issue :)

16:08 <_florent_> somlo: I was planning to update the issue yes, but in the README I just create a link to the issue, not the files directly

16:11 <somlo> _florent_: ok, thanks, that seems pretty straightforward. I'll have a README.md, several configuration files (for busybox and a bunch of .dts files), but then I wanted to make available a bunch of intermediate things such as the cross-compiled busybox binary, the initramfs.cpio file, vmlinux, and, finally, boot.bin (that in addition to the various bitstream files for the three boards I'm starting out with)

16:12 <somlo> I'm just testing my own README.md before uploading it, one final QA pass to straighten out any kinks I can find before going public... :)

18:41 <somlo> _florent_: in simulation, assuming I initialized the RAM with `--ram-init boot.bin`, is there a way to jump to the first RAM address from the bios prompt?

18:42 <somlo> I have my sim configured with --with-ethernet, and (if using rocket) the tftp attempt won't time out in any useful amount of time :(

18:42 <somlo> so I'm hitting <esc> early on, but then I don't know how to just start whatever I side-loaded into ram on the command line...

20:31 <somlo> ok, it's out: https://github.com/litex-hub/linux-on-litex-rocket

20:32 <daveshah> got your first star from me :)

20:43 <somlo> Thanks! :D