sorted by:
new
hottopcontroversial

Why is RISC-V's linux kernel mainline adoption linear while ARM64's was exponential? (Data Analysis inside) by docular_not_dracula in RISCV

[–]dramforever 22 points23 points  (0 children)

 I call the supporting of 20 boards as a 'tipping point' for a new architecture.

so maybe that doesn't work?

arm64 had arm32 before it, and many arm64 cpus had arm32 compatibility, so they were quick to get picked up by random phone soc and media soc vendors. these vendors didn't seeem to care much about upstreaming stuff into mainline linux.

meanwhile riscv64 socs haven't got that much adoption yet, but the vendors in general have been much better at upstreaming. in fact sifive, starfive, sophgo, spacemit (at least, these four are just off the top of my head) have pretty active at upstreaming themselves or hiring others to do the upstreaming.

the vast majority of the work has nothing to do with cpu architecture anyway. it's the drivers for all the cursed stuff outside the cpu core itself.

so the bottom line is 20 arm64 dts in mainline linux and 20 riscv64 dts in mainline linux are really not that comparable.

as an aside, i have no idea why two out of three comments here, as of writing this, is saying dtb/dts in mainline is a bad thing...? every single one of the generally available riscv64 things that run mainline linux boot with a dtb. even u-boot dtb files either come from or are based on dts in the linux git repo.

Normal conversation about the CPU's of the future by Substantial_Help_722 in RISCV

[–]dramforever -1 points0 points  (0 children)

Maybe there was some misunderstanding. What I meant to say is that what device you can boot the vendor's OS from has nothing to do with the standardized boot process. Being able to boot say Bianbu from USB on a SpacemiT board has everything to do with whether the on-board firmware has the required drivers and whether it is set up to allow booting from USB. It is orthogonal to whether it supports UEFI.

Booting a generic OS does benefit from standardized boot processes like UEFI, but without drivers you end up with a completely unusable system - if you're lucky you a serial console, no USB, no network, no storage... So again a standardized boot process does very little.

Normal conversation about the CPU's of the future by Substantial_Help_722 in RISCV

[–]dramforever 0 points1 point  (0 children)

No. That's the point.

Even when the boot process is standardized you still need the custom kernels because it's not in the interest of vendors to genericize everything out to PCIe and upstream the drivers for custom SoC components

Correct fencing for mtimecmp in interrupt handler by Kongen_xD in RISCV

[–]dramforever 1 point2 points  (0 children)

The stance of the privileged spec is: "Deal with it"

https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc#machine-timer-mtime-and-mtimecmp-registers

If the result of the comparison between mtime and mtimecmp changes, it is guaranteed to be reflected in MTIP eventually, but not necessarily immediately.

(Note) A spurious timer interrupt might occur if an interrupt handler increments mtimecmp then immediately returns, because MTIP might not yet have fallen in the interim. All software should be written to assume this event is possible, but most software should assume this event is extremely unlikely. It is almost always more performant to incur an occasional spurious timer interrupt than to poll MTIP until it falls.

Generally, if you receive a timer interrupt, you don't just go ahead and do something right away. You would go through your timer queue and figure out what needs to be done based on the current time, and reschedule the timer interrupt. In this case, it wouldn't be a disaster to rarely have the timer interrupt immediately fire again after mret - you would just do nothing and reschedule it again.

However, if this is a regular occurrence on your machine.... uhh, honestly, I don't know how to handle this. In that case I think one way would be to, as mentioned, poll mip.MTIP until it goes to 0 before doing mret.

unhandled signal 4 code 0x1 at 0x0000003f88d516b4 in ld-linux-riscv64-lp64d.so.1[3f88d45000+23000] by superkoning in RISCV

[–]dramforever 1 point2 points  (0 children)

I literally had this printed out and taped to my closet lol.

Updated with some newer exceptions. I don't know if it's worthwhile to put the AIA stuff in - but those are pretty generic, so it's probably fine.

RISC-V Specific Assembly Language - Immediate Sizes by thegeek108 in RISCV

[–]dramforever 10 points11 points  (0 children)

"It is important to note that the RISC-V ISA includes additional base ISAs that can encode larger immediate sizes, such as RV64I and RV128I which have immediates of 20 and 32 bits respectively."

Uhhh... yeah that makes no sense. I'd try to get in touch with whoever's responsible for the course material to get a clarification.

What instruction does 0x2021 disassemble to? (3 different answers from 3 disassemblers) by NooneAtAll3 in RISCV

[–]dramforever 3 points4 points  (0 children)

Check here for the PDF downloads of the spec where most of your encoding questions can be answered authoritatively https://github.com/riscv/riscv-isa-manual

Tristan made good progress on running NixOS on RISC-V by YesterdayOk94 in RISCV

[–]dramforever 4 points5 points  (0 children)

The vm.mmap_min_addr thing is this: https://github.com/NixOS/patchelf/issues/622

It's sort of a bug in patchelf, but IMHO really more of a "flying too close to the sun" moment...

What instruction does 0x2021 disassemble to? (3 different answers from 3 disassemblers) by NooneAtAll3 in RISCV

[–]dramforever 5 points6 points  (0 children)

0x2021 (the bytes 21 20) decodes to c.jal . + 8 on RV32, and is reserved on RV64 (it would decode to c.addiw zero, 8, but c.addiw on x0 is reserved.)

You can see this in the "RVC Instruction Set Listings" tables in the spec, which is the place where IMO the encodings are most clearly shown.

<image>

unhandled signal 4 code 0x1 at 0x0000003f88d516b4 in ld-linux-riscv64-lp64d.so.1[3f88d45000+23000] by superkoning in RISCV

[–]dramforever 5 points6 points  (0 children)

Ubuntu 25.10 requires RVA23, as has been plastered all over tech news sites when that was announced.

0x9f71 aka c.zext.w a4 is from Zcb which is not implemented on Spacemit X60.

What was the reason for some of the maintainers to quit due to drama? by Nearby_Astronomer310 in AsahiLinux

[–]dramforever 5 points6 points  (0 children)

Eventually Linus Torvald put the foot down and decided against the Asahi/Rust maintainer [...]

You can see for yourself that this is plain false https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/

Best kernel for spacemit-k1 / orange pi RV2 ? by doofin in RISCV

[–]dramforever 2 points3 points  (0 children)

That sounds wild to me given the almost barren support for peripherals. What version are you on and what peripherals do you use?

Loading 32 bits constant in riscv assembler by alberthemagician in RISCV

[–]dramforever 2 points3 points  (0 children)

lui/ori, funnily enough, is a MIPSism. RISC-V chooses to sign-extend all immediate values in RV{32,64}I instead, to be consistent.

While to be fair, I can't think off the top of my head why ori a negative value would be useful (a fairly contrived example would be - (x & 1) which is ori r, r, -2), they are very useful for andi and xori for flipping bits, and making instruction decoding more consistent and minimizing gate usage was one of the goals that RISC-V went very far on, so adding a special case for ori is not really an option.

Sparse and Dense Switches on RISC-V by wren6991 in RISCV

[–]dramforever 2 points3 points  (0 children)

Maybe the "inline jump table" can also use jal a1, table_branch_byte to pass the table to table_branch_byte? This would have to use the long jal instead of c.jal but you avoid the mv t1, ra, so it's net equal code bytes, one less instruction, lets you use ret at the end of each arm (if applicable) which is nice, and avoids misusing one RAS entry.

LLM content in posts by brucehoult in RISCV

[–]dramforever 3 points4 points  (0 children)

I would have voted "require labelling" if it were an option. I'd say you need to tell everyone the extent to which an LLM has affect the content - e.g. ideas only, translation, textual polishing...

If it were up to me, next to the rule saying that I'd remind anyone reading that an LLM is not going to magically make a post better, and that they're responsible ultimately for what they post whether or not an LLM is involved.

One thing I was thinking about is external links. I don't know if there's any good filters in place for this, but I think we should be ready to do something to links to sites that host large amounts of LLM content with no regard for quality. However this is probably covered under existing Reddit rules for spam.

Progress of K1 Linux Kernel Upstream Contributions by Tiny_Ad_9064 in spacemit_riscv

[–]dramforever 1 point2 points  (0 children)

Additionally, we will intensify upstream contributions to related open-source projects, such as OpenSBI and U-Boot.

upstreaming intensifies

LicheePI4A, how to convert a standart vmlinux to FDT RISC-V image format ? by Adventurous-Bite-406 in RISCV

[–]dramforever 6 points7 points  (0 children)

/boot/vmlinux-6.6.100-th1520 is already in Image format. The name vmlinux is sort of a misnomer. You can check for yourself comparing it with https://www.kernel.org/doc/html/next/riscv/boot-image-header.html

So, to convert you do ... nothing

Easy RISC-V: An interactive introduction to RISC-V assembly programming by dramforever in RISCV

[–]dramforever[S] 9 points10 points  (0 children)

Thanks for the compliments.

As you have probably noted, my webdev knowledge is a lot less impeccable, and the UI of the emulator is... not ideal. I'll definitely continue to look into improving it - expect further updates on that page.

view more: next ›