<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)
futarisIRCcloud has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
jersey99 has quit [Quit: Client closed]
bytebucket has joined #litex
bytebucket has quit [Quit: Client closed]
rlittl01 has joined #litex
rlittl01 has quit [Read error: Connection reset by peer]
<tnt>
tcal: are both board the same revision ?
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
<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.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jeffdi1 has quit [Quit: Leaving.]
<tnt>
tcal: you can try iceprog -Q in case some bitstream set the QE=0 non-volatile bit ...
<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).
<_florent_>
tnt: The BIOS is detecting presence of peripherals from presence CSR names , so for now I would recommend renaming your submodules
<tnt>
ack
<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?
<mntmn>
i suspect that the cpu is triggering on edges only?
<mntmn>
to explain better, i can see in /proc/interrupts that the interrupt was recognized many times but it has stopped counting now:
<mntmn>
4: 2673 SiFive PLIC 16 Edge ue11-hcd:usb1
<mntmn>
but in litescope i can see that the interrupt line is high
<mntmn>
_florent_: any idea? does an interrupt line from hdl to vexriscv have to be pulsed?
<_florent_>
The cores from LiteX generate level triggered IRQs and that's what I also think is expecting VexRiscv-SMP PLIC implementation
<_florent_>
So your integration should be similar to IRQs generated from the UART/LiteEth cores
<mntmn>
hmm, but what could cause interrupts to not be registered?
<mntmn>
i.e. i can see in litescope the line is high, but counter in /proc/interrupts does not increase
<_florent_>
I also don't explain it, unless we have a current missmatch between LiteX IRQs and expexted VexRiscv-SMP IRQs
<_florent_>
can you try to modulate the IRQ from your core, just to see if you then see the interrupt increasing?:
<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.
<jersey99>
And unexpectedly, setting the edianness to correct "little" didn't change the behavior
<_florent_>
before compiling the litex_bare_metal_demo, are you also updating:
<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
<mntmn>
ah, the problem was outdated csr.csv
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 252 seconds]
peepsalot has joined #litex
peeps[zen] has quit [Ping timeout: 252 seconds]
FabM has quit [Quit: Leaving]
<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
<tcal>
tnt: my iceprog doesn't seem to have "-Q" ?
Martoni42 has joined #litex
<jersey99>
_florent_ .. Thanks a lot for your help. This makes a lot of sense, and works :)
essele_ has joined #litex
essele has quit [Read error: Connection reset by peer]
essele_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]