| *** tpb <[email protected]> has joined #litex | 00:00 | |
| tcal | tnt: to follow up, I dug out another iCEBreaker board, uploaded the same bitstream, and it worked 100% including tty. So I think the board I was using could have degraded somehow (admittedly, I'm pretty casual about leaving boards lying about my desk among the clutter) | 00:05 |
|---|---|---|
| *** futarisIRCcloud <[email protected]> has joined #litex | 00:58 | |
| *** Degi_ <[email protected]> has joined #litex | 02:10 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 02:11 | |
| *** Degi_ is now known as Degi | 02:11 | |
| *** jersey99 <[email protected]> has quit IRC (Quit: Client closed) | 03:13 | |
| *** bytebucket <[email protected]> has joined #litex | 03:54 | |
| *** bytebucket <[email protected]> has quit IRC (Quit: Client closed) | 04:14 | |
| *** rlittl01 <[email protected]> has joined #litex | 04:37 | |
| *** rlittl01 <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:40 | |
| tnt | tcal: are both board the same revision ? | 07:07 |
| *** FabM <FabM!~FabM@2a03:d604:103:600:acf2:430b:bf1f:6720> has joined #litex | 07:15 | |
| tcal | yep -- v1.0e. The old one *used* to work as expected, so whatever the flaw is, it snuck in in the last couple of months. | 07:15 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 07:58 | |
| *** TMM_ <[email protected]> has joined #litex | 07:58 | |
| *** futarisIRCcloud <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 08:38 | |
| *** jeffdi1 <[email protected]> has quit IRC (Quit: Leaving.) | 09:10 | |
| tnt | tcal: you can try iceprog -Q in case some bitstream set the QE=0 non-volatile bit ... | 12:58 |
| tnt | On another subject: How does one deal with conflict in the CSR namespace :/ I have a custom i2c module with CSR and that prevents /libbase/i2c.c to build because the CSR_I2C_* values are the ones from my block and not the one from the default block (which I don't use). | 12:59 |
| _florent_ | tnt: The BIOS is detecting presence of peripherals from presence CSR names , so for now I would recommend renaming your submodules | 13:11 |
| tnt | ack | 13:14 |
| mntmn | if i have some IP that has an interrupt line which is "level triggered", do i have to do some special stuff to make it work correctly with vexriscv interrupt lines? | 14:18 |
| mntmn | i suspect that the cpu is triggering on edges only? | 14:19 |
| mntmn | to explain better, i can see in /proc/interrupts that the interrupt was recognized many times but it has stopped counting now: | 14:22 |
| mntmn | 4: 2673 SiFive PLIC 16 Edge ue11-hcd:usb1 | 14:22 |
| mntmn | but in litescope i can see that the interrupt line is high | 14:22 |
| mntmn | _florent_: any idea? does an interrupt line from hdl to vexriscv have to be pulsed? | 15:13 |
| _florent_ | The cores from LiteX generate level triggered IRQs and that's what I also think is expecting VexRiscv-SMP PLIC implementation | 15:16 |
| _florent_ | So your integration should be similar to IRQs generated from the UART/LiteEth cores | 15:16 |
| mntmn | hmm, but what could cause interrupts to not be registered? | 15:18 |
| mntmn | i.e. i can see in litescope the line is high, but counter in /proc/interrupts does not increase | 15:18 |
| _florent_ | I also don't explain it, unless we have a current missmatch between LiteX IRQs and expexted VexRiscv-SMP IRQs | 15:19 |
| _florent_ | can you try to modulate the IRQ from your core, just to see if you then see the interrupt increasing?: | 15:20 |
| _florent_ | https://www.irccloud.com/pastebin/83k2emuf/ | 15:20 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 15:20 |
| mntmn | _florent_: ok, i'm gonna try that | 15:22 |
| mntmn | thanks! | 15:24 |
| *** jersey99 <[email protected]> has joined #litex | 15:43 | |
| *** jeffdi1 <[email protected]> has joined #litex | 15:50 | |
| jersey99 | _florent_ Sorry for the bother, but I kind of want to see this through :) .. but are there any unassumed constraints about the BOOT_ROM_ADDRESS? The region seems to get allocated fine during build (base at 0x2000_0000), and I see the CPU trying to jump to that region after bios. | 15:51 |
| jersey99 | And unexpectedly, setting the edianness to correct "little" didn't change the behavior | 15:52 |
| _florent_ | before compiling the litex_bare_metal_demo, are you also updating: | 15:54 |
| _florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/demo/linker.ld#L21 | 15:54 |
| _florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/demo/linker.ld#L31 | 15:54 |
| _florent_ | to use the new memory you added? | 15:54 |
| mntmn | hmm, what would make litescope not continue anymore after [running]...? (with immediate capture). i think i broke it by adding a 12-bit signal to the capture list | 15:56 |
| mntmn | ah, the problem was outdated csr.csv | 16:15 |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex | 16:48 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 252 seconds) | 16:50 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 16:56 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 252 seconds) | 16:57 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 17:05 | |
| jersey99 | Oh .. Do I need to explicitly add the extra regions to the CPU? In that case, to my eyes, I don't see csr region being explicitly added. I will look into this | 17:59 |
| tcal | tnt: my iceprog doesn't seem to have "-Q" ? | 18:00 |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 18:50 | |
| jersey99 | _florent_ .. Thanks a lot for your help. This makes a lot of sense, and works :) | 19:39 |
| *** essele_ <[email protected]> has joined #litex | 19:40 | |
| *** essele <[email protected]> has quit IRC (Read error: Connection reset by peer) | 19:40 | |
| *** essele_ <[email protected]> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:26 | |
| *** essele <[email protected]> has joined #litex | 20:27 | |
| *** essele <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 21:14 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 252 seconds) | 21:16 | |
| *** jersey99 <[email protected]> has quit IRC (Quit: Client closed) | 21:45 | |
| *** jersey99 <[email protected]> has joined #litex | 21:45 | |
| jersey99 | _florent_ I made a minor edit here ( https://github.com/enjoy-digital/litex/wiki/Load-Application-Code-To-CPU ) in regards to my experience. Maybe you could say something about the linker script (I understand it's a side detail). | 21:46 |
| tnt | tcal: oh, my bad, this PR never got merged ... https://github.com/YosysHQ/icestorm/pull/283 | 22:09 |
| bjonnh | those digilent boards are shipping from Taiwan! | 22:12 |
| tcal | tnt: thanks for the pointer, hopefully I can check tonight if it unjams the board | 22:40 |
| *** jersey99 <[email protected]> has quit IRC (Quit: Client closed) | 23:31 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!