<rektide>
anyone know of any resources talking to avalon-st vs wishbone vs axi? is there any work on tilelink?
<rektide>
does anyone have suggestions for how i can understand core sizes? i dont know what i am doing yet, only just beginning, but i'd like to try to understand the impact of adding, say, an sd-card. i'm not sure what i'm adding it to yet though. this would likey be on an ecp5 85f.
<pftbest>
I am trying to debug why ethernet doesn't work and i see that ethcore.mac.core.preamble_errors increase by 1 with each received packet, is that normal?
lkcl has quit [Ping timeout: 276 seconds]
lkcl has joined #litex
<_florent_>
nickoe: I would first recomment starting from litex_sim and the Litescope tutorial at: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC (and make sure you reproduce the results), then adapt this to your own needs. This will give you a starting point that you can progressively adapt.
<_florent_>
nickoe: otherwise if you have empty .vcd, make sure the trace signal is set to 1 in the simulation:
<_florent_>
somlo: nice for the 32-bit CSR, thanks @shorne_
<_florent_>
pftbest: with add_etherbone you should be able to ping the board yes, it's possible there is an issue on the ethphy in your case
<_florent_>
pftbest: You can see the expected behavior with the simulation: litex_sim --with-etherbone and then ping the sim 192.168.1.51
<_florent_>
(on hardware the default eth ip is 192.168.1.50)
<pftbest>
_florent_: do you have any suggestion on how to troubleshoot issues with ethernet phy? I've got ecpix-5 board with KSZ9031 phy. I think the phy itself is working because in the litex console I can dump MDIO registers
<pftbest>
litex> mdio_dump 0 2
<pftbest>
0x00 0x1140
<pftbest>
MDIO dump @0x0:
<pftbest>
0x01 0x796d
<pftbest>
And the values look reasonable to me
<pftbest>
Unfortunately I don't have oscilloscope at hand to check the signal on RXD pins
_whitelogger has joined #litex
Bertl_zZ is now known as Bertl
<nickoe>
_florent_: yeah, well, that is what I did. That is sarting from the litex_sim.py and then I jused added the LedChaser and I am trying to trace that.
<nickoe>
I do get the tracing from the CPU and stuff, but I can't find my leds.
<_florent_>
nickoe: I assume you probably added pins to the Sim Platform to add the LedChaser, so the signals in the dump should have the name of the top level outputs
iTitou has left #litex ["WeeChat 1.4"]
<nickoe>
_florent_: I linked my script before, let me find it, but yes in the sim platform
<_florent_>
ok, and in the dump you don't see the user_led outputs?
<nickoe>
No, so now I just tried with "./mars_ax3_sim_litex.py --with-sdram --sdram-init=demo.bin --trace" (not using the analyzer), but just enabling the trace
<nickoe>
now opening gtkwave ./build/sim/gateware/sim.vcd
<nickoe>
Mm, I see the user_led signals in the TOP
<_florent_>
nickoe: ok, litex_sim does not have a virtual user_led component, so for the LedChaser you'll just see the signals in the dump
<nickoe>
mm, so I thought didn't see that yesterday, but that was probably with the --with-analyzer
<_florent_>
pftbest: For Ethernet on the ECPIX5, I would recommend testing the default litex-boards target with --with-ethernet:
<nickoe>
It appears to works with the --trace option, but with --with-analyzer only I don't get traces, and I am not running with --sim-debug, so self.comb += platform.trace.eq(1) should be set always.
<_florent_>
nickoe: with --with-analyzer, you have to use litex_server and litescope_cli to get your dump:
<nickoe>
hmm, ok, I thought it would trace as it appears to attempt to write a vcd
<_florent_>
The analyzer is storing the captured data in a RAM of the SoC that needs to be read through the bridge once captured
<_florent_>
no, the analyzer is a hardware module that is demonstrated in the simulation but mostly useful on real hardware
<_florent_>
That's similar to Chipscope/SignalTap/Reveal tools
<nickoe>
I can start the simulation with etherbone and see the ip in "ip a", but I can't seem to get "litex_server --udp --udp-ip=192.168.1.51" to connect to it..
<nickoe>
althoguh the remote appears to get "192.168.1.100" and not .51. but changing it ... still no luck
<nickoe>
"Exception: Unable to probe Etherbone server at 192.168.1.100."
rozpruwacz has joined #litex
<_florent_>
nickoe: once the simulation is started, are you able to ping 192.168.1.51?
<rozpruwacz>
Hi, I'm using linux-on-litex-vexrisc project with de0nano board. I successfuly added the litespi core and i can send data through it from within linux. Now i want to add spi device with interrupt line. How i can add gpio input interrupt to the soc and use it with linux ? I was trying to add GPIOIn module but i don't know how to handle it from linux
<rozpruwacz>
side (seems to me that litex,gpio driver does not support interrupts).
<_florent_>
Hi rozpruwacz, the interrupt has been recently added on the GPIO input, so that's indeed possible it's not yet supported by the Linux driver
<nickoe>
yes, I can ping .51
<rozpruwacz>
_florent_ oh great :) is someone working on it or I can try to add support for it ? It would be fun way to get familiar with riscv for me :)
<nickoe>
hmm, now it did connect. odd.
<_florent_>
rozpruwacz: I don't think anyone is working on this currently, this could indeed be a good way to get familar with riscv and contribute
<_florent_>
rozpruwacz: if you are stuck, somlo, shenki_ or shorne_ would probably be happy to discuss linux driver related issues/questions
<rozpruwacz>
_florent_ ok, thanks.
rozpruwacz has quit [Quit: Connection closed]
<pftbest>
_florent_: thanks for the advice. It appears both rx and tx works when using with-ethernet. I don't have a linux image to test full netboot, but I see in wireshark that the board is able to receive ARP replies and I see both tx and rx data in the UART log
<pftbest>
that is good news i think, it means my board is not damaged
<pftbest>
but it doesn't explain why etherbone doesn't work while ethernet is ok :(
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Read error: Connection reset by peer]
pftbest has joined #litex
<_florent_>
pftbest: ah, but it's also possible the timings are not met with Etherbone on this board. Some work has been done on that but it's not yet merged, I'll try to integrate it in the next weeks.