<bonzibuddy>
hey gurus - im pluggin along, trying to get more utilities in my rootfs, but every time i customize the config the system hangs on 'waiting on /dev/ram0...'
<bonzibuddy>
my hypothesis is that im trying to upload an image too big for the mem area? still need to confirm that. hoping someone's worked around this one before
<bonzibuddy>
customize the buildroot config & upload via lxterm***
<futarisIRCcloud>
bonzibuddy: What's the size of your ramdisk in .config and the image size?
freemint has quit [Ping timeout: 276 seconds]
_whitelogger has joined #litex
Guest124578 has joined #litex
freemint has joined #litex
Guest124578 has quit [Remote host closed the connection]
Guest124578 has joined #litex
<Guest124578>
Hi,
Guest124578 has quit [Remote host closed the connection]
pc_inside has joined #litex
pc_inside has quit [Remote host closed the connection]
hello_pico has joined #litex
<hello_pico>
Maybe a silly question : is it possible to make a Vivado project manually which would be similar to what LiteX scripts do ? (I was expecting for a simpier code when looking at the Verilog generated by LiteX)
hello_pico has quit [Remote host closed the connection]
CarlFK has quit [Quit: Leaving.]
<somlo>
_florent_, daveshah: the litedram native port width on the trellisboard is indeed 256, so I'm inclined to bump the hard-coded mem_axi width on Rocket to 256, and downconvert for boards with narrower litedram ports (e.g., ecp5versa at 128, nexys4ddr at 64) but use full unimpeded width where available
<bonzibuddy>
futarisIRCcloud: i'll check that this evening, that's likely the issue
<somlo>
daveshah: trying to build litex+rocket for the trellisboard, and I usually get to 60MHz easily (no need for -nowidelut, plenty of room), but consistently fail to meet the 125MHz for '$glbnet$eth_clocks_rx' (getting in the neighborhood of 115MHz, typically)
<daveshah>
Interesting
<daveshah>
Possibly the larger chip makes placement worse
<daveshah>
or just different Ethernet pin placement or something
<daveshah>
I haven't noticed this with VexRiscv when I've tried previously though
<somlo>
I am now trying with a lower (55MHz) cpu clock, to see if that has some second-order effect on the ethernet timing
<somlo>
but I'm just basically throwing rocks at it :)
<somlo>
if that doesn't immediately make a difference, I'm just going to let it loop
<somlo>
not sure if it's worth trying with the "unmet" ethernet fmax, using --timing-allow-fail
<daveshah>
Yes, definitely
<daveshah>
Another thought is to remove abc9. I think I've seen it reduce Ethernet Fmax in the pat
<daveshah>
*past
<somlo>
ok, forgot about abc9, thanks for that.
<daveshah>
Hmm, looking into this myself and I got 124.63MHz on a first try
<somlo>
yeah, it's all probabilistic... asked for 58MHz, got 62.60 for main, 128.55 for eth... Wish I'd just asked for 60 like earlier :)
<somlo>
I want to get to the good bits, where I use an unhindered point-to-point 256bit axi channel between litedram and the rocket chip :)
<somlo>
find out what that does for my benchmark measurements...
<somlo>
daveshah: any plans to add a trellisboard.cfg to /usr/share/trellis/misc/openocd (in prjtrellis) ?
<daveshah>
This one is pretty old but has always been reliable
<daveshah>
FWIW, there seems to be some hardware variation too. On the other board you sent me, and a board from my own batch; the bitstream you sent seems to work 100% of the time
<somlo>
ha
<somlo>
"memtest ok" \o/
<daveshah>
note there are two ways to try a reset - reloading the svf or pressing SW2, might be a difference between the two
<daveshah>
Interesting
<daveshah>
Possibly something a bit marginal in the controller then
<somlo>
gets wobbly when the main clock gets too low
<daveshah>
Tweaking the +1 and +2 to either +0 and +1 or +2 and +3 might increase reliability
<somlo>
I'm not physically close to my stash of alternative boards, so I'll try the hacks first, see what shakes loose...
<somlo>
daveshah: just for a sanity check: my reset switch is the leftmost of the group of four; if I hit the "standalone" one on the left of the board, I have to reload the svf
<daveshah>
Yes, that's right
<somlo>
can't read the labels on the pcb, my glasses are "tuned" for 20-inch focal distance, i.e. my computer monitor :D
<somlo>
it *never* fails at 75MHz with the vexriscv bitstream
<daveshah>
Yeah, I've never had issues with that bitstream or any other 75MHz bitstream on any board
<daveshah>
OTOH, the same PHY works fine at 55MHz or 60MHz on a Versa
<somlo>
yeah, rocket seems happy on a versa anywhere north of 55MHz
<daveshah>
But, different PCB layouts, double chips might mean longer routing and less margin, ...
<daveshah>
Let me just try a new 75MHz vex bitstream to make sure it isn't a regression
<somlo>
ok, in the mean time I'll try getting a proper 60MHz rocket bitstream, maybe more if I turn off abc9...
<somlo>
seems to pass memtest for me as well (there's a weird delay before I get the "ok" prompt, and "no boot medium found", but it *is* "memtest ok" nonetheless, each time I kick it...
<daveshah>
That's because picorv32 is slow :)?
<daveshah>
I was alarmed by it too at first
<somlo>
ok, so I'll try to figure out how far I can tweak fmax and the litedram cl_sys_latency offsets
<daveshah>
65MHz seems alright here too, but that might be a bit ambitious for Rocket
<daveshah>
seems to be 60MHz where it fails
<daveshah>
As it seems to either work or not (either a lot of failures or none at all, never just one or two failures), it might be a problem with the startup FSM
<somlo>
of course, if any of that tweaking actually turns out to help in a reliable way, we'd have to regression test on the versa, to make sure the modifications aren't mutualy exclusive between the two boards...
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<daveshah>
Hmm, no idea then
<somlo>
was this with a modified 't' (guessing s/8/12/) in ecp5ddrphy.py line #56 ?
<somlo>
I'll eventually work my way up to trying the offsets on line #442, but I'm hoping I can push fmax a few MHz above 60, into "maybe works most of the time" territory :)
<daveshah>
Yup
<daveshah>
You could try an even higher 't' perhaps, it definitely improved reliability for me
Dolu has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<somlo>
daveshah: used --timing-allow-fail, requested 65MHz, officially got 57, passed the ethernet clock timing
<somlo>
running it at 65MHz now, booted linux just fine
<daveshah>
Nice
<somlo>
not sure whether *not* using abc9 helped, I'd have to test that a bit more thoroughly (right now I've been haphazardly trying whatever sticks)
futarisIRCcloud has joined #litex
<somlo>
if that turns out to matter, I'll make it an optional build flag rather than a hardcoded thing
Dolu has quit [Ping timeout: 268 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]