<_florent_>
Melkhior: nice, thanks. A first version by hansfbaier has already been merged in litex_boards, both are probably complementary, we should try to merge them
<Melkhior>
darn didn't notice :-)
<Melkhior>
copy/pasting from the documentation is the one thing I can do ;-)
<_florent_>
:) It will probably still be useful and can help catching errors
<Melkhior>
anyway getting the board at $37 was a good move, as they're now listed as 'quote' :-(
<_florent_>
indeed, I also received mine BTW
<Melkhior>
excellent :-)
<Melkhior>
I also see a targets for deca, is it usable yet ? Though the question is more 'what can you do with LiteX when there's no external memory' I suppose ; i've only ever tried Linux but there's probably some use case that can run out of the FGPA on-board memory I guess.
<zyp>
_florent_, any suggestions for how to troubleshoot etherbone? I'm running the ecpix5 example from litex-boards, slightly modified to call add_etherbone() instead of add_ethernet(), but it's not responding to ARP and it's also not responding to ICMP when manually inserting an entry into the ARP table
pftbest_ has joined #litex
pftbest has quit [Ping timeout: 246 seconds]
shorne_ has joined #litex
shorne has quit [Ping timeout: 245 seconds]
<shorne_>
Hello, On my arty board I switched on etherbone to try to use litescope
<shorne_>
However, as expected, the netbooting no longers works
<shorne_>
I tried to boot from sdcard and for somereason it hangs after trying to read boot.json
<shorne_>
I am probably having issues partitioning/formatting the sdcard correctly
<shorne_>
any suggestions on alternative boot methods? Is there a way to load an image over etherbone? I could write a program to do it, but i assume somethign already exists
<shorne_>
trying litex_term now
rozpruwacz has joined #litex
<Melkhior>
Hello,
<Melkhior>
So I got a bitstream for the MAX10, and it seems OK (including programming) as I see the LEDs do their thing.
<Melkhior>
But I don't know how to see if there's anything on the serial port, as in the target file it's defined as 'jtag atlantic' and I don't know what that is.
<Melkhior>
I seem to have a 'new' tty that showed up when I plugged the USB cable for the usb blaster, but it doesn't display anything in minicom at 115200 or 1000000
<Melkhior>
Any suggestion ? Or maybe I shouldn't expect anything on the TTY as there's no memory for the BIOS code to run in ?
<Melkhior>
(that's the MAX10 on the Deca board)
<Melkhior>
I see lxterm has a --jtag-name that can take 'jtag_atlantic' as an option, but not sure what 'device' to give it
pftbest_ has quit [Remote host closed the connection]
pftbest has joined #litex
somlo has quit [Remote host closed the connection]
<Melkhior>
Well, didn't figure it out so I just replaced the 'jtag_atlantic' thing by a 'normal' liteuart on a couple of pins in the P8 header (in {targets,platforms}/deca.py) and it worked perfectly :-)
<zyp>
_florent_, is it still not possible to run etherbone with dw>8?
<zyp>
I found out it works if I up the sysclk to 125MHz (except then I have problems meeting timing), but upping the dw to LiteEthIPCore doesn't seem to work
david-sawatzke[m has quit [Ping timeout: 268 seconds]
xobs has quit [Ping timeout: 268 seconds]
JJJollyjim has quit [Ping timeout: 265 seconds]
jevinskie[m] has quit [Ping timeout: 268 seconds]
apolkosnik[m] has quit [Ping timeout: 268 seconds]
lkcl has quit [Ping timeout: 246 seconds]
<_florent_>
shorne_: It's possible to do a serialboot over Etherbone, but that's not really fast (so could be an issue in your case with Linux images). If you want to try, you can use --uart_name=crossover --with-etherbone on the arty target.
<_florent_>
then litex_server --udp
<_florent_>
and litex_term bridge
<_florent_>
Another option is to use the Hybrid Ethernet Mac Mode that provides both Ethernet and Etherbone on a different IP address.
<_florent_>
But this is not yet properly integrated in LiteX, so you have to use code similar to this;
<_florent_>
This is probably the option that requires the minimal changes
CarlFK[m] has joined #litex
<_florent_>
Melkhior: For the deca, I tested hansfbaier's initial port with litex_term jtag --jtag-name=jtag_atlantic
<_florent_>
But you can also juste use nios2terminal
<_florent_>
juste/just
<_florent_>
zyp: That's already good you got it working at 125MHz, I remember being able to also use a 50MHz clock with Etherbone on the Colorlight
<_florent_>
zyp: This would need to be investigated more
<Melkhior>
_florent_ Thanks. Didn't know about nios2terminal. My workaround w/ litex' own uart worked for me:-) Now if only there was a memory controller for the DDR3;-) (someone in eevblog's forum is building one with the Deca as a target, but no idea if the interface will be easy to integrate in Litex...)
<_florent_>
zyp: Eventually with LiteScope
lkcl has joined #litex
<_florent_>
Melkhior: Integrating the Altera controller should not be to complicated, I already did that in the past, It would just need a Wishbone/AXI bridge (it's even possible it will already be AXI capable, which would simplify the work).
<_florent_>
Melkhior: Ideally, it would be nice to add a proper PHY in LiteDRAM, but this could be an intermediate solution
<zyp>
_florent_, I've been digging into it and fixed a couple of small things, but I'm still not having any luck with giving LiteEthUDPIPCore dw=16 even at 125MHz
<_florent_>
zyp: not sure 16 has been tested but 8 and 32 have been
<zyp>
I tried that too
<zyp>
yeah, tried it again, still no ARP
<_florent_>
zyp: ok, I really think this is related to the PHY or reset sequence. That would be interesting to add LiteScope on the PHY source/sink and compare with frames on the Host with Wireshark
<zyp>
how do you figure? phy.dw is hardcoded to 8 so the phy behavior shouldn't differ even if the MAC is set to a different dw
<zyp>
I see the width conversion happen in the pipelines in LiteEthMACCore
<_florent_>
I really think this is a low level issue and suspect the packet is already malformed at the phy.source. At least that would be the first thing I would look at, and then add the other source of the stack, up to to the ARP, and then go in the other direction for the returned packet.
<_florent_>
This way, on an isolated network, you can just trigger on phy.source and see all the layers at once
<zyp>
I was hoping to avoid having to set up another wishbone bridge to be able to use litescope :)
<zyp>
I just think that since it works for dw=8, the issue should be somewhere above the StrideConverter
apolkosnik[m] has joined #litex
sajattack[m] has joined #litex
leons has joined #litex
shoragan[m] has joined #litex
xobs has joined #litex
david-sawatzke[m has joined #litex
JJJollyjim has joined #litex
jevinskie[m] has joined #litex
<_florent_>
zyp: that's a good hypothesis, but a design not correctly constrainted or incorrect reset sequence can also produce strange behavior. I'll try also have a look at this tomorrow, that would be nice to have the Etherbone and the hardware UDP/IP working on the ECPIX5
<zyp>
hmm, litescope is not getting a trigger on arp.rx.sink.valid
<pftbest>
zyp: does your ethcore.mac.core.preamble_errors.status increase for each incoming packet? I get a strange behavior that with one of my routers this number increase for each packet consistently, but it stays 0 with the other router.
<pftbest>
doesn't work on both of them though, so it's probably not related
<pftbest>
just a curious thing i noticed
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<zyp>
tools are not super cooperative today and since I'm not getting a trigger on arp.rx.sink.valid, I'm instead looking at some random udp broadcast packet it picked up, and as far as I can see the mac output looks sane with dw=32
<shorne_>
_florent_: thanks, I will try some of those options
<zyp>
ah, here we go, it appears to be an endianness problem