pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
C-Man has quit [Ping timeout: 255 seconds]
chiefwigms has quit [Ping timeout: 246 seconds]
pftbest has joined #litex
chiefwigms has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<mithro>
Melkhior: unclear
<Melkhior>
mithro: thanks; in my head DRM was targeted at higher-end GPUs and might require a larger baseline of functionalities for acceleration...
<Melkhior>
Though at this point I look more at what NetBSD is offering rather than Linux
<mithro>
Melkhior: I think DRM will eventually replace all the older fb stuff in the future...
<Melkhior>
mithro: which might leave lower-end/older hardware, or soft-soc, with no console acceleration :-(
<Melkhior>
Side-note: thanks to Litex I have been able to use a USB mouse and mount a USB stick on my SPARCstation (with some help of Dolu1990 to figure out some bugs)
<Melkhior>
And now I also have the SDRAM working (somewhat) as a RAM disk on which I can swap :-)
<mithro>
From what I can see DRM, modesetting and similar interfaces are much better at handling weird stuff than fb stuff ever was.
<mithro>
Like it understands things like clocks, connectors, power supplies, cables, etc...
<Melkhior>
mithro: to be honest I can't remember much about the FB stuff, haven't touch my FB driver in like 15 years...
<mithro>
Fb was hacks on hacks from what I've seen
<Melkhior>
I was about to try and figure out how to do some memory copy in the Litex FB for an accelerated console when I discovered Linux had pulled the plug, so didn't move forward
<Melkhior>
:back
<Melkhior>
well it was working, and that's a whole lot better than nothing :-)
<Melkhior>
Having an accelerated FB driver was very useful back in the day, compared to the basic default driver
<Melkhior>
But I guess we have to accept that things change...
<Melkhior>
But having FB disappears makes me feel old - the only bit of code I have in the Linux kernel is there...
<Melkhior>
We'll have to see how DRM and simpledrm evolve, and perhaps someday there will be a OSH simpledrm-accelerated graphic device!
<Melkhior>
fingers crossed :-)
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<gatecat>
ime, DRM has more complexity but it tends to rely a lot less on driver specific hacks
<gatecat>
I remember an old FB driver where a lot of the configuration could only be done via writing to files in sysfs
<cr1901>
NetBSD-on-LiteX would be fun, but RISCV support just isn't there :/
<gatecat>
:(
<cr1901>
(although I think the POWER support might)
<Melkhior>
gatecat: in my case it's NetBSD-on-SPARC I'm using Litex with :-) But yes it would be nice to have NetBSD on RISC-V; in particular for RV32
<cr1901>
World decided that Linux is the One True Unix, Unix Is Dead, etc
<cr1901>
That it's okay for [REDACTED] as long as it allows users to get work done.
<Melkhior>
cr1901: oups, you were the one talking about NetBSD not gatecat, sorry both
<cr1901>
litex supports SPARC?
<Melkhior>
cr1901: no, I'm using Litex cpu-less to add devices to a SPARCstation, see the link I posted if you want detail (it's only mildly relevant here)
<Melkhior>
It could support SPARC by using e.g. LEON (Columbia's ESP project does it), but there's probably not a lot of future in that
<cr1901>
oooh right... I remember seeing that
<Melkhior>
Even Cobham-Gaisler has moved from SPARC (LEON) to RISC-V (NOEL-V)
<cr1901>
Anyways, lm32 doesn't have a future either probably but no plans to remove support for that I don't think
<cr1901>
(I guess partially b/c of nostalgia, and well, it's not a bad CPU core for being written in Verilog)
<cr1901>
(It was the "original" LiteX core)
<Melkhior>
Microwatt looks nice, but I'm not sure it can save PowerPC... and neither will a 2.5k$ Talos Blackbird or the even worse price/performance ratio of the $2k AmidgaOne X5000
<cr1901>
I'm not interested in an x86, ARM, and RISCV-only world, so I will fight against it :)
<Melkhior>
cr1901: good fight :-) and thanks for the LEON5 link, guess they still need SW compatibility to some level, good to know SPARC is not fully dead yet :-)
<sorear>
give it five years, "riscv" will cover a larger range of incompatible systems than exist today in the general market :p
<cr1901>
I like the base ISA, and I _love_ the insn encoding of the base ISA. Everything else bites
<Melkhior>
I do plan to try Microwatt some day... I've always liked PowerPC's rlwinmi and similar instructions. RISC but not dogmatic, some real-world considerations seeped into the design
<cr1901>
(And I'm not entirely convinced that "bolting on the compressed ISA to expand to the full ISA" is a good idea for timing. But that's a feeling, not any hard data.)
<Melkhior>
yes, RISC-V is too simple by default to be truly efficient. It's a great teaching tool, but not a great production design.
<Melkhior>
You need some of B, or some of the L/S instructions they added in PULP
C-Man has joined #litex
<cr1901>
Ehhh, that doesn't bother me too much. The base set is nice, and extremely happy they didn't mandate mul/div in the base ISA (and the counters/CSRs in the E ISA)
<Melkhior>
C seems to cause a lot of problems... There's been some issue with it in Vexriscv (should be fine now), and i'ts not the only one
<cr1901>
My own RISCV core will implement "enough of the privileged ISA such that interrupts in C/Rust work" and that's it
<Melkhior>
hehe, missing MUL cause SPARCv7 a *lot* of problem performance-wise!
<cr1901>
All the components are connected together, just need to write the microcode
<Melkhior>
That's why it was mandatory from V8 onward...
<Melkhior>
Truth is, I don't buy the "one size fits all" idea. Some compromise do not work at all scale.
<Melkhior>
Another lesson from the so-called Scalable Processor ARChitecture :-)
<Melkhior>
which core is that?
<cr1901>
Melkhior: Not public yet, but it's called "sentinel"
<cr1901>
Meant to be a "management CPU" without the baggage of ME :)
pftbest has quit [Remote host closed the connection]
<Melkhior>
cr1901: embedded/securuty then
<Melkhior>
I'm at the other side of the scale - day job is HPC, if it doesn't reach teraflops it's not for me :-)
<cr1901>
embedded more than security. Fit into very smol places, like femtorv32, but "my take on it because I'm too vain to admit femtorv32 prob fits my needs"
<Melkhior>
And so far, RV64GVC hasn't proven itself
<Melkhior>
well call it a learning tool, and then it's no longer vanity :-)
<cr1901>
hmmm
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]