<sajattack[m]>
How hard is it to port rocket linux to another litex board?
<somlo>
sajattack[m]: Thanks! Right now there are several boards known to work at github.com/litex-hub/linux-on-litex-rocket
<somlo>
smp support is just a matter of sufficient fpga capacity -- I'll post patches after I get some sleep :)
<sajattack[m]>
Only 5 I thought
<somlo>
it's all mostly upstream litex, if you look at the build command lines in the readme, so other boards *should* also work, only no one's tried yet
<sajattack[m]>
Cool I'll have to give it a shot
<sajattack[m]>
I've bumped into some problems with rv32gc support in various ways and curious to see if the grass is greener on the other side
<sajattack[m]>
initial results on my acorn_cle_215 pcie abomination..... the crossover `litepcie_util uart_test` reboots my pc
<tpw_rules>
sajattack[m]: have you had any issues with flaky compilation? it seems the basic litex examples only work on my nitefury if compilation is lucky
<tpw_rules>
i make small changes and then they break
<sajattack[m]>
I had a couple issues I guess
<sajattack[m]>
nothing major
<sajattack[m]>
somlo: I guess I need to write a dts?
<tpw_rules>
like what? i guess nitefury support seems kind of broken to me, but it's not great for you either
<sajattack[m]>
a couple times I had weird brokenness but I'm not sure if it was the compiler or pebkac
<sajattack[m]>
here goes nothing...
<sajattack[m]>
`[LXTERM] Uploading boot.bin to 0x80000000 (15698616 bytes)...`
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
mc6808 has quit [Quit: Ping timeout (120 seconds)]
<_florent_>
sajattack[m]: can you check the timings with Rocket @ 100MHz on the Acorn?
<_florent_>
tpw_rules: the false path constraints have been updated on the Acorn design, can you provide more info on your failures? is it an issue with PCIe enumeration? or something else?
C-Man has quit [Ping timeout: 264 seconds]
<Melkhior>
somlo: awesome! how much resources are needed to get to dual-rocket or more?
<Melkhior>
_florent_: is there some standard way to 'remap'/'alias' some of the wishbone address space? The SDRAM is mapped as one contiguous block, but I need a small block (probably the last 1-8 MiB) read/writable at a different address for compatibility reasons
<Melkhior>
I can always had my own Wishbone slave + dedicated DRAM port, but it feels a bit overkill
<Melkhior>
TIA
<_florent_>
Melkhior: We don't have this feature currently no, the custom DRAM port solution seems the way to go for now
<Melkhior>
OK thanks - might also try to 'remap' (in a somewhat hackish way) in my bridge, could be less resource-intensive
<Melkhior>
Another question - i see the Micro 4K uses GTPs for HDMI, where other board uses regular pins (and so there's 2 HDMI PHY for 7-series), any significant benefits to that?
<Melkhior>
kind of wondering if it's worth investigating for an hypothetical hdmi-enabled custom board
<_florent_>
The main benefits is for high resolutions: regular Artix7 IOs can do up to 1.25Gb/s (so already overclocked at 1080p60/1.485Gbps), GTPs can do up 6.6Gbps, so are fine even for 4K
<Melkhior>
_florent_: OK so definitely worthwhile, even though GTPs are quite limited in numbers... would you expect any other change needed in HW design?
<Melkhior>
(it seems the Mini 4k schematics are not public so I can't look at them for 'inspiration' :-) )
<_florent_>
The mini 4k has a 75dp159 between the GTPs and HDMI ports
<Melkhior>
_florent_: so more complex because I need level-shifters... thanks for the info
<Melkhior>
maybe 4K on a SPARCstation would be too ambitious, might have a go at lower resolution first :-)
<geertu>
Melkhior: That's only an improvement of 8x, compared to the original resolution ;-) And probably you go for increased color depth, too?
* geertu
never noticed before that 1920 * 1080 = 2 * (1152 * 900)
<Melkhior>
geertu: Not at first, I'm thinking of emulating a dumb cg3, plenty of sample codes out there (drivers & Qemu emulation)
<Melkhior>
also using 8 bits per pixels would save on memory bandwidth, so easier to use higher resolution
<Melkhior>
Of course eventually I would love to have a HW-accelerated 24-bits FrameBuffer with full X11 support, but that's a loooooooooooong way away :-)
<Melkhior>
(cg3 also have Forth OpenBIOS support so probably can get console support as well)
geertu has quit [Read error: Connection reset by peer]
geertu has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Ping timeout: 264 seconds]
mtretter has quit [Quit: leaving]
mtretter has joined #litex
pftbest has joined #litex
C-Man has joined #litex
<acathla>
The FOMU toolchain I was using doesn't like the new LDFLAGS in common.mak. What's the right toolchain to use?
pftbest has quit [Read error: Connection reset by peer]
geertu has joined #litex
<acathla>
_florent_, Thanks, will be usefull but that didn't change anything... I changed $(LD) to $(CC) in my Makefile and it seems OK now.
Stary has quit [Ping timeout: 240 seconds]
Stary has joined #litex
<somlo>
Melkhior: on the nexys4ddr, a single core (w/o gateware FPU) Rocket/Litex uses 32% of LUTs. A 4-core (FPU-less) setup goes up to 76%
<david-sawatzke[m>
florent: Could you take a look at the 32 bit mac PR in liteeth in the near future, please? I've used it quite a bit in the last few weeks (with the softcore) and it seems to work without issues.
<david-sawatzke[m>
I don't want to build too many future changes on these shaky grounds
<Melkhior>
somlo: thanks! that's on a A7-100T so it's not huge ; I don't think Rocket can share FPU between core the way VexRiscv can so adding FPUs might be difficult
<Melkhior>
But it's really great to have SMP RV64IMAC in Litex :-)
willcode4[m] has joined #litex
hjimenez93[m] has joined #litex
<hjimenez93[m]>
Hi! I recently learned about LiteX, its awesome! I was wondering if you know of an existing or WIP open-source alternative to Xilinx' ERNIC IP for RDMA.
<hjimenez93[m]>
Btw, I learned about it in GRCon
<somlo>
Melkhior: I think the way it goes with Rocket is either all cores have FPUs or none do
<somlo>
there's room for 4-core FPU-enabled cores on the nexys-video or genesys2, but I haven't tried running anything there yet
<somlo>
s/cores/cpus/
Crofton[m] has joined #litex
dmiller[m] has joined #litex
<Melkhior>
somlo: That's the nice thing w/ VexRiscv - you can share a single FPU implementation between 1 or more core (AMD Bulldozer-like), so you get most of the benefits of HW FPU and a limited size impact
<Melkhior>
genesys 2 is a lot more expensive than A7-100T boards...
<Melkhior>
Maybe dual-core RV64GC would fit? FPUs aren't that big...
<somlo>
Melkhior: the cool thing about the genesys2 is that a quad-core rocket litex design (with gateware FPUs) passes timing at 100MHz (as opposed to 50, like everywhere else so far)
<somlo>
which should be exciting, once I get around to running it
<Melkhior>
Yes, the 2x freq increase sounds good :-)
<Melkhior>
Wonder how many rockets would fit in a VCU128 and at what speed - the HBM sure would be able to supply enough bandwidth :-)
<somlo>
you could try to build it with variant `full4d` or `full4q` and see what the utilization percentage is... Then we could create a variant with more cores (linux currently supports up to 8, but even that could probably be increased)
<somlo>
s/linux supports/the current linux litex rocket defconfig supports/
<somlo>
to be precise...
<Melkhior>
I suspect the 8 hart limit might be in OpenSBI as well
<Melkhior>
Anyway rhetorical question, HBM is not yet supported, the VCU128 is not yet supported, and mine is for 'real work' only :-/
<Melkhior>
You can fit a lot of stuff in that FPGA :-)
<gatecat>
hmm, I've got the Alveo U250, but I think some work would be needed to take advantage of more than one DDR4 channel (and I don't think we got DDR init entirely reliable on all channels either)
* somlo
is dreaming of the day one could just use yosys+nextpnr on it directly :)
<Melkhior>
yosys+nextpnr on the Artix-7 and DDR3 at a good level of performance would be a great starting point before moving to Kintex and HBM :-)
<somlo>
pythondata-cpu-rocket has 4-core variants with and without gateware FPU, and the provisional litex support is in PR 1040, if any of you want to tinker with it
<Melkhior>
somlo: if only I had the time :-/ the little I have I waste on SBusFPGA at the moment
<somlo>
Melkhior: speaking of, I'm going to grudgingly stop this for today and start paying attention to my $DAYJOB :D
<_florent_>
david-sawatzke[m: sorry yes I'll try to review and merge it this week
<_florent_>
hjimenez93[m]: Hi and welcome :) (Personnaly, I'm not aware of ERNIC IP open source alternative).
<_florent_>
gatecat: for the Alveo U250, the easy way to integrate the 4 DDR channels is to have 4 standalone LiteDRAM core (each itself being a SoC) and another top level SoC doing the integration
<_florent_>
gatecat: I already have this running on the XCU1525
<_florent_>
gatecat: when using a small CPU, the extra resources used by the standalone core is negligible
<_florent_>
gatecat: and that's in fact very similar to the MIG that embeds a Microblaze for each controller :)
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 264 seconds]
FabM has quit [Quit: Leaving]
<mm001>
I'm still trying to figure out why the rgmii_test.py of the chubby75 project crashes on an incoming udp packet while the linsn_rv901t.py from litex-hub does not.
<mm001>
Apart the sys_clk_freq, I don't really see a difference for the ethernet phy...
<mm001>
By the way, if I change the sys_clk_freq from 133e6 to 75e6 in rgmii_test.py, it doesn't work at all, can't even get a ping response.
<mm001>
But I can't see why the sys_clk_freq should work at 75e6 with linsn_rv901t.py when it does not with rgmii_tes.py
<mm001>
Could that also be related to the crash on incoming udp packet?
peeps[zen] is now known as peepsalot
<jevinskie[m]>
You could probably fit a "couple" of rocket cores on this 480k LE Arria 10 board you can get for ~$150 USD. 👀 Anybody happen to have schematics? https://www.ebay.com/itm/174944904362