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
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
-DCMAKE_PREFIX_PATH=${EPREFIX}/usr/$(get_libdir)/cmake
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
/usr/bin/cmake
cmake version 3.18.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
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.
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-collab/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…
Great post and I thank you for the information. I share your sentiment for great quality tools and for communities that support these things and people who use them.
My files seem to work fine but it turns out that makepkg didn’t even create the final packages. It doesn’t give any error message for not being able to generate the packages.
I gave up on creating arch from gentoo for now
Since an image of parabola was released I will use that one if it works.
I was able to mount it and retrieve the rootfs. I have no interest in a vm, I rather use the real thing.
Mounting it is not a big deal as long as you are familiar with the type of image
Just in case you would have issues, here are the commands needed as root to get the rootfs into an xz compressed file
modprobe nbd max_part=8
qemu-nbd --connect=/dev/nbd0 parabola-riscv64.qcow2
mkdir rootfs
mkdir images
mount /dev/nbd0p1 rootfs
cd rootfs/
tar cvfJ …/images/parabola-20210621.tar.xz *
I hope to be able to use this and chroot on it.
Once I get it working on the beaglev with the correct kernel I will see if I can replace systemd with openrc.
One thing that I have noticed is that the lib directories are not handled the same way as on gentoo.
I do have archlinux on my ryzen computer but find gentoo to be faster so that is my main work system. I do use archlinux at work, I didn’t want to spend the time needed for gentoo…
For embedded systems I often prefer archlinux, that is what I use on my beaglebone black boards.
On gentoo /lib and /usr/lib are different directories as well as /lib64 and /usr/lib64
/lib64 as well as /usr/lib64 used to not have any files but a directory called lp64d or lp64 depending on whether you want hard to pass arguments in FP registers or not
Recently the gentoo maintainer(s) have changed this so you get lp64d → . or lp64 → . and the library are on the lib64 directories
On this it looks just like on my Ryzen computer,
lib → usr/lib
lib64 → usr/lib
usr/lib64 → lib
So my question to the parabola maintainer(s), which protocol is used for your system, lp64d or lp64?
I guess I could figure out eventually
Michel, perhaps this should be in a different thread as your question is about a specific version of a specific OS and not a general purpose “monitoring” query . Perhaps a question directly to the Parabola team can help you with your port.
There’s really no reason to make a distinction for 64 bit on RISC-V Linux. TPTB have already said that 64 bit is the floor. A 32 bit Linux abi and official kernel just won’t exist. K210 is probably the wimpiest RISC-V Linux system we’ll see. Similarly, on any Linux for RISC-V, you can count on hardware FP.
I was able to chroot and install a few applications. So it looks good so far.
If I can create packages then that it will be a good platform work with.