YA RISC-V port thread

cmsigler · 2020-11-09 22:03:36

Hi,

Older thread located here to avoid necro-bumping.

Is anyone working in earnest and has made significant progress on a port to the new RISC-V systems popping up? I'm interested in 64-bit myself, but I've also read about 32-bit SoC boards out now. I'm mainly asking because this inexpensive RISC-V SoC board was just announced yesterday. IIUC the target price is US$12.50, which is right up my alley Timeline on this product is said to be two months (Jan., 2021).

Here is my wiki sandbox. Be warned: I'm a n00b at this. Laughter is appreciated but please be gentle Please fix all errors you find and add as you are able. Mind you, if Real Life intrudes I may not get anything done

Some "zero experience" questions I have:

* Is tooling (scripting, etc.) used for ALARM more-or-less turnkey, and could it be adapted for RISC-V? Or will this be a from-scratch project?
* If the board I referenced isn't vaporware, can the native Linux OS (TinaOS, said to be a Debian derivative) be used to easily bootstrap Arch?
* What about drivers, device tree, etc.? What about the bootstrapping process and whatever type of BIOS boots the board at power-up?
* What cute acronym should be used? ALRISC? RISC-VAL? [Insert additional stupid marketing-type acronym here]

I know I have a lot of reading to do and experience to gain. Anyone who can chime in is appreciated, just in case this turns out to be a Platform of the Future(TM) Thanks, all

Clemmitt Sigler

edit: Typo
edit 2: Proposed humorous project name: "RISC-V Business" (pronounced Risk-Vee, not Risk-Five

Last edited by cmsigler (2020-11-16 18:00:13)

Awebb · 2020-11-10 13:59:41

I have no actual clue, but I did some digging.

If the board I referenced isn't vaporware, can the native Linux OS (TinaOS, said to be a Debian derivative) be used to easily bootstrap Arch?

I'm not sure if "easily" is the right word, but if you can compile the contents of base-devel (and its dependencies) on that platform, you should have a chance.

You'll need to come up with your makepkg.conf, but I think it only passes all the stuff through to the compiler. You've probably found this already: http://five-embeddev.com/toolchain/2019 … c-targets/

Beyond that... good luck and have fun!

cmsigler · 2020-11-11 13:17:57

@Awebb

Awebb wrote:

I have no actual clue, but I did some digging.
I'm not sure if "easily" is the right word, but if you can compile the contents of base-devel (and its dependencies) on that platform, you should have a chance.
You'll need to come up with your makepkg.conf, but I think it only passes all the stuff through to the compiler. You've probably found this already: http://five-embeddev.com/toolchain/2019 … c-targets/

Nope, I hadn't found that yet. Thank you Shows you how little hard work I've put in Note to self -- Do more research on RISC-V documentation....

My (very sketchy) thinking is to use the KVM/qemu RISC-V target to build stuff. I don't understand a lot about this process/techniques. The main thing I have zero knowledge of is the embedded aspects like device tree. I only know about this from messing with ALARM.

I doubt I will have the free time to make significant progress. Not surprising because these projects seem to spring out of team efforts. And having actual experience developing for different architectures would help, which I don't have. I'm just really curious about arches other than i386/x86_64, and this is the New Kid on the Block

Thank you again!

Clemmitt

Awebb · 2020-11-11 15:37:38

I'd also firmly stare at whatever the fine folks over at Gentoo do: https://wiki.gentoo.org/wiki/Project:RISC-V

cmsigler · 2020-11-11 16:16:57

Awebb wrote:

I'd also firmly stare at whatever the fine folks over at Gentoo do: https://wiki.gentoo.org/wiki/Project:RISC-V

After using DEC UNIXes (and VAX ), I cut my Linux teeth on (of all things) Yggdrasil when I was working in research. For my first personal system, early on I focused on Debian which I ran from '95 until early '04. When I got tired and frustrated with trying to get great bleeding-edge software to build -- cross-installing Sid unstable libraries and trying to keep all those balls in the air -- I decided to evaluate every distribution out there. I settled on Gentoo, which didn't deter me because I had also worked with Free, Net and OpenBSD.

I finally went Arch with one box, then all the rest of them soon after, in 2012. So, I'm extremely rusty with Gentoo, but it's something I should be able to handle. The old "muscle memory" should bring it back.

And I think you're exactly right about Gentoo RISC-V. I was about to say that perhaps it would make the most sense to do the easiest parts first, which also happen to be the largest gains "by volume" as it were. By this I mean, get a RISC-V VM up and running and build Arch tooling. (I wonder if there are any cross-distribution tools to build Arch pkgs on Gentoo, or Gentoo pkgs on Arch? THAT would be an interesting and potentially valuable project....) Then building packages would "just work."

Yeah, right There will be blindside architecture, #ifdef/autoconf, etc., bugs that will prevent packages from building. Then, patch and upstream.

So, not an easy task, but probably easier. But if one focuses on base and base-devel, then gets all the core pkgs built, that should be real, valuable progress. Then, on to more

My complete lack of embedded development experience means hitting an embedded target like the upcoming inexpensive SBC will require time to read, learn and practice. The idea of building foundational pkgs inside a VM seems much more achievable. Plus, it's something that one or a group could pick away at in their available time

Thank you for helping me bounce ideas off you. Maybe this limited plan makes some sense now

Clemmitt

cmsigler · 2020-11-13 17:59:46

Hi again,

I missed this one -- the PicoRio SBC planned for 1H2021:

RISC-V International blog

CNX Software

Tom's Hardware

OS News

Now I remember reading this, but obviously was too busy to care in September As the 1.0 version is a headless unit, YMMV

Clemmitt

Awebb · 2020-11-14 10:10:47

Another question would be: Are you interested in maintaining a complete Arch for RISC-V or just in getting started?

cmsigler · 2020-11-14 13:40:15

Hi,

Awebb wrote:

Another question would be: Are you interested in maintaining a complete Arch for RISC-V or just in getting started?

Let me answer that emphatically : Just getting started.

I absolutely do not have the time to devote to leading a RISC-V Arch project It's a very attractive intellectual problem and a mountain still not fully explored, but I'm not "the guy." I am not a comp. sci./IT paid professional. FWIW I imagine someone who is would be qualified to be a lead, and that's not me....

Maybe if the can can be kicked farther down the road a team of qualified, architecture-experienced leaders would be interested in taking over in order to finish crafting initial efforts into a fully supported outside project like ALARM and ArchLinux32. Here's hoping....

It's taken me a few days to recollect/relearn about disk images and running them under QEMU. I looked back into the mists of time, and I last tinkered with creating disk images from scratch, shockingly, in 2007. I was curious enough about TinyGentoo (which was unofficial, although Gentoo has official uclibc and musl support now) to build/bootstrap QEMU disk images. I wrote scripts which automated the process. This worked well. Very satisfying

I still haven't worked with archlinux-cross-bootstrap on github. If it hasn't bitrotted too badly it would be simple to cross-build the base-devel pkgs. I'd also like to cross-build other repository pkgs. Although they could be built inside a RISC-V VM, IIUC cross-building them would be faster. IF almost all PKGBUILDs and pkgs can be successfully auto-patched and -built, the job won't be agonizingly slow and tedious. But obviously this remains to be explored.... I hope I can make enough progress to find out how possible all this will turn out to be for me

Thanks again!

Cheers,
Clemmitt

eschwartz · 2020-11-15 01:03:16

An arch developer has fiddled with this in his spare time: https://github.com/felixonmars/archriscv-packages

Completely unofficial repos for arch=(riscv64): https://archriscv.felixc.at/repo/

Should probably be enough to bootstrap and test stuff out on real hardware. But obviously it's still very Here Be Dragons, and every time Felix mentioned it, there was something else to fight with. Well, new CPU port, hardly unexpected, someone's gotta lead the way.

cmsigler · 2020-11-15 01:40:14

Hi, Eli,

eschwartz wrote:

Should probably be enough to bootstrap and test stuff out on real hardware. But obviously it's still very Here Be Dragons, and every time Felix mentioned it, there was something else to fight with.

"Here Be Dragons" indeed! Thank you for pointers to Felix's work. Wrapping my mind around ways to tackle this to make some progress building and testing.

Clemmitt

Arch Linux

#1 2020-11-09 22:03:36

YA RISC-V port thread

#2 2020-11-10 13:59:41

Re: YA RISC-V port thread

#3 2020-11-11 13:17:57

Re: YA RISC-V port thread

#4 2020-11-11 15:37:38

Re: YA RISC-V port thread

#5 2020-11-11 16:16:57

Re: YA RISC-V port thread

#6 2020-11-13 17:59:46

Re: YA RISC-V port thread

#7 2020-11-14 10:10:47

Re: YA RISC-V port thread

#8 2020-11-14 13:40:15

Re: YA RISC-V port thread

#9 2020-11-15 01:03:16

Re: YA RISC-V port thread

#10 2020-11-15 01:40:14

Re: YA RISC-V port thread

Board footer