_franck_ has quit [Remote host closed the connection]
_franck_ has joined #litex
indy has joined #litex
<cr1901_modern>
_florent_: Wanna feel old? You've been running your company for as long as I've known how to use FPGAs (minus one year- I learned in early 2010)
<daveshah>
I started playing with FPGAs in 2015...
<zyp>
I started playing with FPGAs in 2007, but I never progressed much from there, so I'm still a novice :)
<geertu>
daveshah: You used a very impressive learning curve ;-)
<cr1901_modern>
daveshah: I fell out of love w/ them in 2012, but fell back "in love" with them in 2015. So that would be a 3 year gap where I didn't touch them lol
feldim2425 has quit [Ping timeout: 272 seconds]
feldim2425 has joined #litex
Melkhior has joined #litex
<Melkhior>
Hello, I'm trying to get linux-on-rocket-litex to work on my board, but the memory fails (bus errors: 0/256 addr errors: 8192/8192 data errors: 524288/524288). A similar configuration with VexRiscV works fine. However VexRiscV is running at 100 MHz,with the memory at 800 MT/s. Rocket is running at 50 MHz with the memory at only 400 MT/s. Could
<Melkhior>
that be the reason ?
andrewb1999 has joined #litex
<Melkhior>
(Artix 7, 35K, SoC barely fit but passes timing at 50 MHz, yet to try higher clock)
<daveshah>
Yes, there have been problems with running litedram at reduced clocks in the past
<daveshah>
I thought they had been fixed but evidently not. Can you see if a 50MHz VexRiscv also fails?
<Melkhior>
Thanks. Any way to run the memory at more than 4x the CPU clock ?
<daveshah>
Not sure, I don't think it would be possible without some big changes but _florent_ is the one to comment there
<Melkhior>
IIRC, never tried a slower VexRiscV. Will try to find the time to test that, it would help narrow the issue.
<daveshah>
yeah
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Zguig has quit [Quit: Ping timeout (120 seconds)]
Melkhior has joined #litex
<Melkhior>
With rocket at 66 MHz (and at 75 MHz but some minor negative slack so might not be relevant) memory fails as well.
<Melkhior>
With VexRiscV at 66 MHz memory fails as well
<Melkhior>
Guess the board requires a fast controller
<Melkhior>
Synthesizing VR5 @ 80 MHz now ...
<Melkhior>
Sorry @ 75 MHz as well, PLL failed for 80 MHz
<daveshah>
This is really something that should be fixeable in litedram, we managed to make lower frequencies work successfully for ECP5 in the end
<daveshah>
unfortunately, it's also beyond my experience to suggest how to fix it...
<Melkhior>
VexRiscV should let me figure out what's the 'minimum' speed
<Melkhior>
I wanted to try Rocket but it's far from critical
<Melkhior>
I have a lowly Artix 7 35K -1, Rocket might work on a bigger/higher speed grade FPGA
<Melkhior>
With VexRiscV at 75 MHz memory fails as well, no surprise
<Melkhior>
Thanks for the help
<felix_>
_florent_: congrats!
<_florent_>
Melkhior: We are not able to do a proper write leveling on Artix7 due to the lack of ODELAYE2 (that are present on Kintex7 and Ultrascale), we are using a shifted sys4x_dqs to compensate: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/arty.py#L47, that's possible some manual adjustments will be required on it to run at a frequency lower than 75MHz on Arty
<tpb>
Title: USB-FPGA Module 2.13: FPGA Board with Artix 7, EZ-USB FX2 and DDR3 SDRAM. (at www.ztex.de)
<_florent_>
Melkhior: ah, you are not testing on Arty?
<Melkhior>
No, the Ztex board + my SBus carrier to supply the micro-sd card slot
<Melkhior>
Do you think I should upstream my platforms/targets for them ?
<_florent_>
we could if it's not too specific
<_florent_>
Melkhior: I just tested 75MHz on Arty, it's passing, going to test 60MHz
<Melkhior>
standalone ZTex is commercially available, but has no peripherals so I have the LEDs for the debug board ; my carrier is OSHW but I doubt anyone will build one :-)
<Melkhior>
is there some simple procedure for that test I could try?
<Melkhior>
need to fix bench/arty.py to create bench/ztex.py for a start I guess
<_florent_>
Melkhior: yes you can do some tests, can you copy/paste these magic commands?:
<andrewb1999>
_florent_: Related question, are you using the arty design that uses an S7PLL or an S7MMCM? I have been using S7PLL as symbiflow doesn't fully support MMCM yet but I have noticed less stable DRAM even with vivado.
<Melkhior>
... at some specific speed or any will do ? (I have a 82.67 MHz loaded)
<Melkhior>
I have S7MMCM in my targets/*ztex.py, using Vivado
<_florent_>
Melkhior: test it at a speed that is was not working, ex 60 or 75MHz
<Melkhior>
OK, will have to regenerate the bitstream to test
<Melkhior>
will report
<Melkhior>
thanks for the help !
<_florent_>
Melkhior: can you also share the results of the calibration when testing? This can be useful to understand
<_florent_>
andrewb1999: in case you have troubles with the LiteDRAM on Arty with Vivado, please fill an issue on LiteX (with the logs of the calibration), I'll have a look
<andrewb1999>
_florent_: Will do that when I have a chance.
<Melkhior>
_florent_ With a 60 MHz VexRiscV, your magic commands make things work
<_florent_>
somlo: thanks! I'm feeling old with this... (even if "only" 35 :))
Zguig has quit [Quit: Connection closed]
<somlo>
experience has taught me that 35 is *not* old ;)
<Melkhior>
somlo I had compiled my own boot.bin, but it doesn't work; not sure if it fails to load or fails to run:
<Melkhior>
litex> sdcardboot
<Melkhior>
Booting from SDCard in SD-Mode...
<Melkhior>
Booting from boot.json...
<Melkhior>
boot.json file not found.
<Melkhior>
Booting from boot.bin...
<Melkhior>
Copying boot.bin to 0x80000000 (15701872 bytes)...
<Melkhior>
[
<Melkhior>
... and then nothing.
<Melkhior>
will have to try with yours to compare. DTS is the same than nexys4ddr, with twice the ram and no ethernet. Not sure if I fixed that properly...
<somlo>
sounds like the path from sdcard -> dram (dma into rocket, and axi point-to-point to litedram back out of rocket)
Zguig has joined #litex
kgugala has joined #litex
<somlo>
so it's probably a question of what command line you used. Also, depending on the native width of litedram on the Arty, you should pick the `linux | linuxd | linuxq` variant (64 vs. 128 vs. 256 bit native litedram width)
<Melkhior>
Same result with your boot.bin
<_florent_>
somlo: yes it seems the DMA from LiteSDCard is not able to access the DRAM
cr1901_modern has quit [Ping timeout: 264 seconds]
<somlo>
Melkhior: right, so it doesn't matter what's in DT or the kernel, this is a bios level problem
Zguig9 has joined #litex
<somlo>
Melkhior: by "command line" earlier I meant the command to build your (rocket) bitstream for the Arty
<somlo>
_florent_: do you happen to remember off the top of your head what the native litedram width is on the Arty ?
kgugala_ has quit [Ping timeout: 256 seconds]
<Melkhior>
I'm not sure I have 128 bits, I should try linux as well
<somlo>
oh, ok, not an arty board, I somehow assumed that from the context, might have misread it
<_florent_>
somlo: that's 128-bit on Arty yes
<somlo>
and yeah, 128bit is linuxd
<Melkhior>
I can try 'linux' as well just in case, I'm pretty sure it's not linuxq
<Melkhior>
mmmm, the board has just the one chip, shouldn't that be 64 bits ?
<Melkhior>
_florent_ the +1 solves the problem for me, now w/ Rocket it passes memtest and then goes straight to the boot failure, no need for the magic commands, thanks
<_florent_>
Melkhior: ok good, I'll adjust this
<Melkhior>
synthesizing with "linux" instead of "linuxd" to see if I'm 64 and not 128 bits on that board
<Melkhior>
... how is that set up for VexRiscV ? I don't remember telling it either of those ...
<_florent_>
Melkhior: if your board has a 16-bit DDR3, the native width of the controller will be128-bit
<Melkhior>
so it's 128-bit I think, as the documentation says to use 16-bit in Xilinx MIG
<_florent_>
Melkhior: for VexRiscv we are generating the VexRiscv cluster automatically from the dram width
cr1901_modern has joined #litex
Zguig has quit [Quit: Connection closed]
<Melkhior>
oh that's right, now I remember: the width even appear in the Verilog filename when using SMP in my setup, it was 128 (Ldw128)
<Melkhior>
so definitely linuxd
kgugala has quit [Read error: Connection reset by peer]
<Melkhior>
so the failure is elsewhere...
<somlo>
ok, so with Rocket there's a special DMA bus, on which the sdcard gateware has master mode, and the Rocket has a slave port
kgugala has joined #litex
<somlo>
Rocket will then route those requests through its own internal "backplane" and out over the mem_axi port that's hooked point-to-point to LiteDRAM
<somlo>
that path is broken somehow for you
<Melkhior>
OK, thanks for the explanations (and the help!)
<Melkhior>
Could I have broken that from a wrong DTS ? That's the only part that is really new (the board platform/targets are identical with VexRiscV, the whole SoC is straight from GitHub)
<somlo>
Melkhior: nope, the DTS comes into play only once boot.bin has been transfered into RAM, and execution transferred to it
<Melkhior>
(I'm guessing no as you seemed to think the nexys4ddr boot.bin should load...)
<Melkhior>
OK
<Zguig9>
Hi guys, I have a few questions again. I'm working on flashspi and board ECPIX5. I had first an issue with specific clock pin as described here: https://github.com/YosysHQ/prjtrellis/issues/158
<Zguig9>
I finished by just removing the associated core clk pinout and have this finally:
<somlo>
you're firmly stuck somewhere in the LiteX bios (litex/soc/software/liblitesdcard/litesdcard.c)
<somlo>
Melkhior: not clear it was *you* who broke anything, it's just that nobody has ever tried Rocket+Litex on your board, and there's "unknown unknowns" to deal with whenever something like that happens :)
<Melkhior>
I could have a very marginal microsd-card; I designed the carrier board with the microsd-card slot - and whike it works fine with Litex/VexRiscV in SD-mode, it mostly fails in SPI mode. And I've yet to succeed to use the microsd-card in my own design for the board's "primary" purpose in my SPARCstation.
<Melkhior>
Rocket is in SD-mode so is in a configuration that can work hardware-wise, but there might still be issue if litesdcard is used a bit differently in Litex/Rocket vs LItex/VExRiscV ...
<Melkhior>
as you said - 'there's "unknown unknowns" to deal with' :-)
<Melkhior>
anyway thanks everyone for the help :-)
<Melkhior>
last question - does the Rocket BIOS support serialboot ?
<Melkhior>
with lxterm
<Melkhior>
that would bypass the problem
<somlo>
Maybe spi-mode sdcard will work with Rocket ? Just throwing things at the wall at this point, but I got nothing else :)
<_florent_>
Melkhior: maybe you could do more testing with the sdcard_xy commands of the BIOS first
<_florent_>
try to init/read/write a data block
<somlo>
(I got both spi- and native litesdcard going on the nexys4ddr, so "theoretically" they both should work)
<somlo>
and yeah, what _florent_ said
<Melkhior>
_florent_ for some reason I can't interrupt the boot process; the BIOS initialize the memory then goes straight to load boot.bin, can't stop it (I could re-break the memory controller that stops it ;-) )
<Melkhior>
I'll rename the boot.bin
<_florent_>
also, it seems the BIOS is able to copy SDCard blocks from the SDCard to the SRAM (since able to find boot.bin and the size), but not to DRAM
<_florent_>
Melkhior: pressing EST or Q during during the boot should interrupt it
<_florent_>
ESC
<Melkhior>
didn't manage to interupt even with q, but then I've a weird setup (I'm using a beaglebone white and some jumper cables as a serial console... )
<Melkhior>
anyway - I can read block all right, and the first is OK (i've seen it so many times trying to fix my design I know exactly what bytes are non-zero by now... sigh ... )
<somlo>
_florent_: if copying sdcard -> SRAM works on *Rocket*, then DMA routing through Rocket's backplane is OK, and we're talking the ability to send bits to LiteDRAM over the AXI dedicated link that's the problem
<Melkhior>
seems serialboot would work, but at 115200 sending 15+ MiB is going to be long...
<Melkhior>
Can I just pass '--uart-baudrate 1000000' to match LInux/VexRiscV default of a 1MBit/s serial port ?
<Melkhior>
Let's try and see :-)
<Melkhior>
anyway getting late thanks a lot for all the help :-)
Zguig9 has quit [Quit: Ping timeout (120 seconds)]
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Melkhior has joined #litex
<Melkhior>
To finish - my boot.bin did load through serialboot, I get 'liftoff', the kernel starts and eventually stops after: