_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
cr1901_ is now known as cr1901
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<jevinskie[m]> Is there any reason I shouldn’t be able to run a no-mmu build of Linux with pretty much any litex supported risc-v core if I disable all the extensions in the kernel? Linux on LiteX SERV anyone? ;P
<cr1901> Idk if it was w/ LiteX specifically, but gatecat did that once
<cr1901> not on SERV, but noMMU linux running nextpnr on a softcore
<tnt> He did ?
<tnt> Also, even nommu might still require atomics support.
indy has quit [Ping timeout: 248 seconds]
indy has joined #litex
<geertu> tnt: As long as it's not SMP, working around the lack of atomics shouldn't be too intrusive
<swetland> yeah, linux should be able to build on single processor platforms with atomic ops based around disabling interrupts. or you could emulate the atomic ops in machine mode but that'd likely be much more overhead
<tnt> I know that I ended up using machine mode in my case, there didn't seem to be any "simple" way to have the kernel not generate the atomics instructions.
<tnt> (but then serv won't do machine mode so defeats the original point)
<tnt> I'm sure you can modify the kernel so it emulates them fully but it's not just "flicking a switch", you'll have to actually code it.
<swetland> possible. I'm used to the ARM support where they already had paths for machines/cpus without atomic ops
<tnt> riscv linux support is "relatively new", so it's definitely not quite to ARM level of feature/choice completeness.
<tnt> and they, quite logically, focus on what actually make sense to run linux on, rather than "cool proof of concept that are useless for any practical thing".
<swetland> I think it's great that people are getting linux booting on their soft cores. nice stress test.
<swetland> but I also think it's sad that there's so much obsession with linux to the exclusion of all else at times
<swetland> modern linux is a very heavy platform to run on a 50-100MHz core with memory measured in the 10s of MB
<tnt> My personal opinion is that linux on fpga is pointless _unless_ you're specifically tryuing to test/prototype a heavy duty softcore you're targetting for a future ASIC or something. Other than that you're better off with something more lightweight, or if you need linux, pick a FPGA with a hardcode.
<swetland> I'd agree with that
<tnt> The rest is fun / cool hacks / learning / ... sure, enjoy the fun. But don't go to prod with that.
<swetland> working with the integrated hard cores is fun. I learned a lot about AXI3/4 last time I worked on a ZYNQ project.
<swetland> I'd love to see FPGA vendors start including RISCV hard cores. A9 is a fussy cpu to work with. And RV32/RV64 would save them a bunch of money that'd go to ARM otherwise ^^
<tnt> The crosslink nx has a bit hybrid approach. It has a RISC-V ALU core and register files.
<tnt> Not a full risc-v but it can help making a core much lighter and faster.
davebee has joined #litex
<swetland> oh nifty. forgot about that.
tedh_ has quit [Remote host closed the connection]
tedh has joined #litex
<cr1901> tnt: I found the article I was thinking of (atomic support w/o atomic insns) https://lwn.net/Articles/314561/
<tpb> Title: User space atomic ops on ARMv5 and earlier [LWN.net] (at lwn.net)
<cr1901> They are called the "kernel user helpers". I suppose no reason to impl them for RV tho https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
<tnt> cr1901: yeah for sure. I just wanted to point out it's not just a config option ATM. There is a bunch of them hardcoded in various piece of inline asm that will need to be dealt with.
<tnt> although that article seesm to be about providing atomics to user space. Not atomics used in the kernel itself.
<cr1901> The term "atomic" is so severely overloaded that I can't tell from context typically
<cr1901> Anyways, linking that was also partially for future-me when he forgets in 6 months again :P
jdmux has quit [Quit: Connection closed]
<_florent_> The interest I can see for Linux on FPGA is the flexibility it offers to control a system, when you don't want or can't use a Zynq, using a SoftCore with Linux can be interesting and with the size of current FPGAs, running Linux is relatively cheap in term of resources.
<_florent_> So with on a standalone system using a large FPGA, where 90% of the processing in done pure logic and that just need simple external control/status, I found running running Linux interesting.
<_florent_> With the chip shortage, I've also seen clients stuck because they were using Nios SOPC builder and the Intel chips they were using on their products was no longer available, similar things with Xilinx devices, etc... Running Linux on the FPGA even if using slower and using FPGA resources has also the advantage of being vendor agnostic, so can be and advantage over performance on some products.
<_florent_> I also had different demands from industrials wanting to create Linux capable SoCs based on VexRiscv/LiteX for Efinix FPGAs to replace some ARM SoCs, so it seems pricing in quantity and performance of Efinix FPGAs make this interesting.
<_florent_> But yes, that's still a very niche/specific market for now
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
jdmux has joined #litex
jdmux has quit [Quit: Connection closed]
lexano has quit [Ping timeout: 246 seconds]
lexano has joined #litex
davebee has quit [Quit: Leaving]
lexano has quit [Ping timeout: 256 seconds]
<swetland> oh I think running an OS on a softcore is super useful. I just think Linux is extremely heavy when you could use something lighter weight.
lexano has joined #litex
<_florent_> funny test I did in 2020 on a big Ultrascale FPGA:
<_florent_> It's also not that bad on the Acorn CLE215+:
<tnt> My point wasn't so much that you don't need soft core ... but as swetland says is you don't needs linux capable ones.
<swetland> oh I'd say often you even want a linux capable one (MMU, etc)
<swetland> just that you could run something much lighter weight than linux on it in many situations
<Wolfvak> Is the CLE215+ even available for purchase anywhere these days?
<swetland> just the linux *kernel* is 10-20MB these days
<tnt> Wolfvak: if you find them somehwere, let me know :)
<Wolfvak> looking for relatively cheap "big boy" fpga boards, I've kinda outgrown my ecp5-25f already lol
<swetland> now if your software stack needs linux's complexity and it fits, great. but for adding a software control layer you can often get by with a lot less bulk
<Wolfvak> tnt, will do... after I buy their entire stock first /s
<tnt> Wolfvak: blackmagic declinks
<tpb> Title: DeckLink – Tech Specs | Blackmagic Design (at www.blackmagicdesign.com)
<tnt> Ultrascale FPGA with 2 DDR3 banks and pcie 8x.
<tnt> for like < 600$ off the shelf.
<Wolfvak> funnily enough my bottleneck is not ram, but you can never have enough of it anyway
<Wolfvak> I'll read up on the "homebrew" capabilities, thanks for the advice
<_florent_> this Decklink is also interesting: XC7A100T / 2x 16-bit DDR3 / PCIe Gen2 X4 for 200$: https://www.blackmagicdesign.com/fr/products/decklink/techspecs/W-DLK-32
<tpb> Title: DeckLink – Spécifications | Blackmagic Design (at www.blackmagicdesign.com)
josuah is now known as _-c-y-b-e-r-_
_-c-y-b-e-r-_ is now known as josuah
josuah has quit [Quit: WeeChat 3.4.1]
josuah has joined #litex
josuah has quit [Client Quit]
josuah has joined #litex
FabM has quit [Quit: Leaving]
zjason` has joined #litex
zjason has quit [Ping timeout: 248 seconds]
<swetland> interesting that it has a mini-usb port... what's that for?
<_florent_> for SPI Flash programming (through a small atmel)
<tnt> (propriatary stuff though :/)
<jevinskie[m]> I wish one of the light BSDs had good RISC V support but that doesn’t seem to be the case so I’m trying Linux. I’ve used zephyr before and enjoy it for microcontrollers but I have the ram for a shell and dammit I’m lazy and want one! :)
<swetland> if you want something *really* light (though more an educational tool than a production system): https://github.com/mit-pdos/xv6-riscv
<swetland> it's a reimplementation of UNIX v6 for RISCV. used for an os class at MIT