Development progress monitored?

Since things are pretty quiet I was wondering if there was a matrix of sorts that could be shared with everyone with current status’s of where things are both hardware and software / supported ongoing etc etc.

Would be a good idea I think to atleast keep us all somewhat upto date.

@nsollars I have been keeping the README updated in this repo with links to the beaglev-starlight repo:

Some highlights

1 Like

Fantastic thanks

I’ve been working trying to get the mate desktop compiled on gentoo. I’ve had two big obstacles. poppler and rust would not compile. With rust it would compile for hours and then barf. For poppler that is a bug in the latest releases. I haven’t seen it on my Ryzen computer but it will not compile at all on riscv64, cmake can’t find the cmake installation.
I fixed the rust issue by installing the rust-bin instead of trying to compile it. I will revisit the issue later on.

For poppler I found a solution which is to add
to local “mycmakeargs=( …” in the ebuild script

The third issue I have is for the compilation of free pascal. I found a solution for that. Fedora has a binary for it. I will use it and create a few ebuild like I had created for the arm boards a few years ago when there was no hardfloat support for lazarus or arm boards. The first ebuild is a binary one use the RPM from Fedora. I then use that to create a gentoo binary and after that I create a new binary using the previously compiled binary. At the time I was working with the debian guy to get it working. Once I get free pascal compiled I will do lazarus which is the gui , it looks like a clone of Borland 6 Delphi. You can actually port Delphi packages to lazarus. The problem is a catch 22 issue. In order to compile free pascal you need a free pascal compiler which doesn’t exist in gentoo. gentoo still doesn’t have support for arm 32 bits or 64 bits.

There’s really not enough information there for anyone to help you, Michel.

If you’re trying to use Gentoo and Gentoo doesn’t have support for ARM, it’s not likely to have support for RISC-V - unless you add it.

I’m not familiar with Poppler, but it looks like it’s part of the Fedora distribution and has been building and running regression tests for years. zathura-pdf-poppler | Package Info | Fedora RISC-V BeagleV is running those rv64g Linux binaries from years ago, just as expected.

cMake is present on the Fedora distribution that’s where most of the BeagleV action is happening. (Other distros are working on bringing up their own infrastructure; Fedora was just the first out of the gate.)

[root@fedora-starfive ~]# which cmake ; cmake --version ; head -5 /proc/cpuinfo
cmake version 3.18.4

CMake suite maintained and supported by Kitware (
processor	: 0
hart		: 1
isa		: rv64imafdc
mmu		: sv39
uarch		: starfive,rocket0

As for ‘catch 22’, most environments solve this via cross development. It’s pretty well understood through the industry.

If you have questions that are specific to BeagleV, we can help but we need WAY more to work on than you’ve given us. Unless you’re actually DOING OS development starting with a supported OS is a pretty good foundation, for example.

My comments were for other people working on gentoo. I am familiar with Fedora, redhat was my favorite for a while. I’ve been using gentoo for years. I find it more useful and easier to customize than Fedora or Debian. The closest thing would be arch linux.

There is very good support from gentoo people on arm or riscv. What is missing is the support for pascal. I guess that us old timers who prefer pascal to C are a smaller group and the maintainers of gentoo are not part of that group.

I had similar issue when I wanted to have a running Free Pascal on my mips board.

I was hoping to get Arch up and going on this platform as it happens.

I haven’t seen any info on an arch linux port on the beagleV so I started my own.

I got stalled on my gentoo due to a bug with x11-themes/adwaita-icon-theme
I reported the bug to gentoo but it looks like a duplicate of a bug that was listed 2 months ago.
I will wait a few weeks to see if anyone got a fix

Meanwhile I will work on getting my archlinux done.
Aside from that my gentoo works nicely. Without that theme file I cannot create my mate desktop.

I can’t put the repository on my website as the owner doesn’t support git so I will need to find a place to put it.
Once I get something working I will post a note on the group as to where the git repository will be.

1 Like

personally id suggest gitlab but thats just my opinion,

I got an Email this morning telling me that I can setup a git repository on my suzielinux website.

Sounds nifty, perhaps we can start by testing with renode?.

Index of /parabola-ports/riscv64/ looks like a promising start. (I know it’s not strictly Arch, but if it works with nothing proprietary in QEMU it will get there.)

I still have a bit of work to do. Since I could not find a working archlinux I am creating one from scratch, actually mine will be more like artix since I do not like systemd at all. I am using gentoo where I have create a pacman package and the tools needed to create a basic stage to boot on the target. I am in the process of creating the base files.
To compile I use fchroot which I ported to gentoo from funtoo. To test I am going to use my BeagleV board.
I could compile on the board but fchroot is much faster. In order to get things to work I had to disable all the sandbox stuff. With the sandbox enabled I can’t compile anything.
I also had to recompile app-misc/pax-utils with -seccomp otherwise I get tons of messages saying that it can’t run seccomp, which I wouldn’t want to run anyway.

Just as reference do you have toolchain info / options that need to be supplied, I have built toolchains for maixduino/K210 but was wondering if there were any specifics for this one.

For cross compiling I use the one I created on Gentoo
crossdev -t riscv64-unknown-linux-gnu

On the gentoo image I have gcc 11.1.0 on

My gentoo image, I call gentoo-riscv64 and I have a script that creates an image for it using losetup.
The only thing that I cross compile is the kernel. I haven’t changed the u-boot that is on the device as it works for me.
The crashes on boot seen in Fedora, I have never had on gentoo so I didn’t bother updating it.

I find it slower to chroot on the micro SD so I chroot on a copy that is on my computer.
To work on the archlinux version I created a basic gentoo image which I called arch_riscv64
To chroot on this I run this as root (not sudo):
fchroot arch_riscv64
I had to create a user to compile files since makepkg refuses to run on root
I had to mess around with the default directories to satisfy makepkg.
Most of the packages require a nodeps to compile but I first check to see that the packages that it complains about are actually installed.
Since the system is gentoo, that script would have no clue since it thinks that it is running on archlinux.
To exit the chroot I type exit and go on directory and run “umount -lR *”
You would have to change the locale, my image is set for fr_CA and my keyboard is cf. I do support french, english, spanish and chinese in my gentoo images.
You would have to add support for other languages if yours isn’t one of those. I choose to simplify my image with the only languages that interest me.
You would add the locale in the locale.gen file on etc and run locale-gen

So far it is working good. If anyone wants to work on it I could provide the image. I don’t know if you could chkroot on it from archlinux, debian or other.
The system I work that on is gentoo.

I use the chain in Homebrew for all my gd32v, k210, bl602, and BeagleV work. I consciously avoid vendor-specific code at the tool level. I don’t even really change compiler flags beyond those necessary for rv32 vs rv64. Of course, BeagleV has little reason to care about rv32…

Some day I may have to care about Vector, where it looks like we may need chip specific branches to fully appreciate, but we’re not there yet. For now, it’s pretty much one size (ok, rv32 might be a second size) fitting all for compilers, debuggers, linkers, assemblers, and such.

It comes from GitHub - riscv/riscv-gnu-toolchain: GNU toolchain for RISC-V, including GCC which is highly quality controlled and maintained by pros that are employed by silicon vendors. Some of the lead committers have been involved in embedded GNU since the early/mid 90s.

We’re lucky to have such good quality tools…