<slagernate>
I can't seem to get the software/demo working on a crosslink-nx eval board. litex_term is hanging when I try to upload anything. Same behaviour when I try e.g. the wishbone tool on this [icebreaker-litex tutorial](https://github.com/icebreaker-fpga/icebreaker-litex-examples) (although at least in this case I am getting `screen /dev/ttyUSB1 115200`
<slagernate>
to work. Can someone share or point me to an example crosslinknx setup? Kind of disappointed how difficult this has been.. was getting similar errors as this closed issue, https://github.com/enjoy-digital/litex/issues/814, which took a while to overcome.
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
slagernathan has joined #litex
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
slagernathan has quit [Client Quit]
Brinx_ has joined #litex
Brinx has quit [Ping timeout: 268 seconds]
nelgau_ has joined #litex
nelgau has quit [Ping timeout: 264 seconds]
Guest8389 has joined #litex
Guest8389 has quit [Client Quit]
<minute>
i have the VideoFrameBuffer base set to 0x50000000. my memory goes from 0x40000000-0x80000000. i see a semi random pixel pattern on screen. but if i run a mem_test 0x50000000 0x100000, for example, there's no change. i think that the LiteDRAMDMAReader is somehow reading a different location. what could be the issue?
<minute>
i can read video_framebuffer_dma_offset and i see it is cycling.
<minute>
and the video_framebuffer_dma_base is > 0xf0009800 00 00 00 50
<minute>
if i do mem_copy 0x50000000 0x40000000 0x100000 i also see no change on screen
<minute>
but mem_read 0x50000000 shows all 0xff now, so def. the content has changed
<minute>
is there some kind of mmu remapping involved so that i have to give the videoframebuffer a different address than the physical memory address, _florent_ ?
<minute>
i'm building vexriscv with --cpu-count 1 --with-coherent-dma
<minute>
if i do mem_write 0xf0009800 0x40000000 to change the dma base address, i can see different pixel content, but instead of all white it is just a different semi-random pattern (looks like uninitialized memory). so the base address does _something_, but does not point at the expected memory address
<minute>
aha, mem_write 0xf0009800 0x10000000 gives me all white!
<minute>
so the video dma base has to be 0 if it has to read from the start of dram
Brinx_ has quit [Remote host closed the connection]
indy has quit [Ping timeout: 265 seconds]
philpax_ has quit [Quit: Connection closed for inactivity]
<gatecat>
slagernate: unfortunately, this seems like it's probably a problem somewhere in the oss stack - testing with the evn board radiant works but oxide doesn't
<gatecat>
I will try and investigate but that is unlikely to be before next week as I'm heading out for some time afk fairly soon
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
<gatecat>
slagernate: as a workaround for now, using picorv32 instead of vexriscv works
<gatecat>
(I think the problem might be somewhere in memory inference and related to the vexriscv caches but don't hold me on that one, still doing some investigation)
<gatecat>
I'm building the SoC from litex-boards with `python ~/litex-boards/litex_boards/targets/lattice_crosslink_nx_evn.py --toolchain oxide --build` for reference
<MoeIcenowy>
BTW I saw RocketChip tagged 1.4 today
indy has joined #litex
<somlo>
maybe it's time for an update to `pythondata-cpu-rocket` :)
<somlo>
I was planning on that before diving into trying to debug Fedora booting on litex+rocket, but $DAYJOB keeps getting in the way...
<minute>
there's no linux driver for litex i2s yet, correct?
<slagernate>
gatecat: sadly, litex_term is still hanging for me even when using picorv also, likely this is a simple mistake of mine, but when using radiant as toolchain, synpwrap is failing with `Fail to run synpwrap -prj lattice_crosslink_nx_evn_impl_synplify.tcl -log lattice_crosslink_nx_evn_impl.srf` and `@E| Mal-formed command line - please check for extra