<forksand>
_florent_: I see the MAC set there, but the value there isn't what gets set on boot (linux-on-litex-vexriscv). Each time the FPGA is flashed, even with the same .svf, it will generate a new random MAC on boot.
<forksand>
the "traditional" user space tools for this don't work either, fwiw. (`ip`, `macchanger` network/interfaces, etc)
<mithro>
forksand: This is with LiteEth?
<mithro>
forksand: I believe kgugala's team was working on Linux drivers for LiteEth so might have some insight into making that work -- it's probably just something missing from the driver?
<forksand>
mithro: ya, with LiteEth.
<mithro>
forksand: Likely the current driver doesn't do anything to set the mac address...
<forksand>
mithro: _florent_ I see that it gets set in LiteX when TFTP booting to the static value you pointed to in bios/boot.c. But when the linux kernel boots up and the liteeth kernel module loads, it sets it to a random MAC, not the one in the bios.
<mithro>
forksand: Sorry, you have reached the limit of my surface level knowledge, I could probably dig into it but I'm afraid I don't have the time right now....
<john_k[m]>
futarisIRCcloud: interesting re Panologic G2 DDR2, although that's still using MIG
<john_k[m]>
"By lowering the clock from 300MHz to 125MHz, I was hoping to not need calibrated IOs (and thus no ZIO pin), and that's exactly how it worked out." coudl be helpful hint though
lolsborn has joined #litex
bonzibuddy has joined #litex
<bonzibuddy>
hey litex gurus - anyone around that has experience with the versa ecp5? im super n00b and cant seem to get the thing to begin loading the prebuilt binaries... it just mucks around with the demo that came out of the box
<bonzibuddy>
gonna RTFM but if anyone has quick pointers, i'd love to hear em!!
<bonzibuddy>
i've gotten as far as setting the jumpers as suggested - i get some pretty esoteric jtag errors on the make.py --load, and an unresponsive process when i try lxterm loading over serial
<bonzibuddy>
daveshah you spooky bastard i just got that exact example working not 2 minutes ago
<bonzibuddy>
so the issue - i have a versa ECP5 board and not an ECP5G :) had to tweak the makefiles and some openocd conf files were also off
<bonzibuddy>
of curious note, my board has "ECP-5G" silkscreened on it, but the "-5G" is sharpied out. weird. anyways, thanks for digging that up for me!
<daveshah>
There have been a few variants of the board
<bonzibuddy>
so to get the prjtrellis working, i had to specify a different arg to nextpnr-ecp5
<bonzibuddy>
from --um5G-45k to --um-45k. I'm having trouble figuring out where that equivalent is in linux-on-litex-vexriscv
<daveshah>
For linux-on-litex-vexriscv you actually want --um45k and --speed 8 on the nextpnr command line
<daveshah>
Otherwise the timing results will be very pessimistic, less important for a blinky but more annoying for Linux
<daveshah>
I can't remember how to do that on the LiteX side either though
<bonzibuddy>
heh, ok. thanks. i imagine its in the litex-boards defs??
<bonzibuddy>
poking around now
<bonzibuddy>
platforms/versa_ecp5.py:202 might e it
<bonzibuddy>
wow, that did it
<bonzibuddy>
successful upload anyway
<bonzibuddy>
:D loading the image
_franck_ has joined #litex
forksand has quit [Read error: Connection reset by peer]
forksand has joined #litex
freemint has joined #litex
_franck_ has quit [Remote host closed the connection]
<somlo>
forksand: re. liteeth linux driver, I think I've bumped into the same thing on 64bit Rocket (I "ported" the 32bit vexriscv linux driver to 64bit, and it's working well, except for the mac address thing you also encountered)
<somlo>
attempts to read the mac address from hardware fail with a "load access fault", so I commented it out and went with the random on-the-fly alternative:
<somlo>
forgot all about it, was going to circle back and take a closer look later, unless it's one of those rare problems that just go away if I ignore it long enough :D