mkdocs.yml # The configuration file.\ndocs/\n index.md # The documentation homepage.\n ... # Other markdown pages, images and other files.\nThe VisionFive 2 SBC is the second generation of SBC in the VisionFive SBC lineup. This lineup of SBCs contains SoCs with the CPUs that use the RISC-V open computing ISA.
This Wiki contains the necessary information a user needs to know before using Rocky Linux on the VisionFive 2 SBC.
","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#technical-guide","title":"Technical guide","text":"","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#hardware-specifications","title":"Hardware specifications","text":"Item Description Processor/SoC StarFive JH7110 (rv64imafdcbx with up-to 1.5GHz max freq) Memory LPDDR4: 2GB/4GB/8GB Storage SD card slot SPI flash for u-boot Video Output HDMI 2.0 MIPI-DSI Multimedia Camera with MIPI CSI (up-to 2160p@30fps) Decoding: H.264 & H.265 at 2160p@60fps Encoding: H.264 & H.265 at 1080p@30fps JPEG Encoder and Decoder 1/4-pole stereo audio Connectivity 2x RJ45 Gigabit Ethernet (some models have 1x 100Mbit instead) 4x USB 3.0 (some models have 2x USB 2.0) M.2 M-Key NVMe drive slot Power in USB-C port: Qualcomm Quick Charge 3.0 compatible GPIO power in: 5V/3A PoE (\"pin compatible with RPi PoE HAT\") GPIO 40-pin GPIO header Dimensions 100mm x 72mm Button(s) Hardware reset button Other Debug pin headers","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#software-statusinformation","title":"Software status/information","text":"At the time of writing this Wiki, the software support is still being upstreamed by the hardware vendor. More details about their upstreaming efforts and the merge status of each component can be viewed at rvspace.org.
","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#relevant-software-repositories","title":"Relevant software repositories:","text":"Following are the necessary arch/board specific software repositories. These are here for curious tinkerers and Rocky Linux maintainers. Suffice to say, as a normal user, you are not expected to touch/compile any of these items
","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#fully-upstreamed","title":"Fully upstreamed","text":"TBD)u-boot (package name: TBD)
linux (package name: TBD)
third party software tools/drivers (package name: TBD)
To install Rocky Linux on the VisionFive 2 SBC, there is one pre-requisite that needs to be satisfied. That is to update the board firmware to v2.11.5.
Editor's note: StarFive (the hardware vendor) is almost done sending in mainlining patches for u-boot and we should be able to switch to upstream u-boot soon. Our u-boot package for the VisionFive 2 should automatically update the board firmware to whatever version we support. But the following section is present nonetheless, for the users who have an outdated firmware than what we (Rocky Linux) have a minimum spec bar for.
","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#pre-requisite-update-board-firmware","title":"Pre-requisite: Update board firmware","text":"NOTE: PLEASE READ THESE STEPS AND CAREFULLY FOLLOW THEM. IF DONE INCORRECTLY, YOUR BOARD MAY GET BRICKED!
visionfive2_fw_payload.img
sudo dd if=sdcard.img conv=sync status=progress bs=1M of=/dev/sdX
mkdir temp-dir
sudo mount /dev/sdX4 temp-dir
sudo cp u-boot-spl.bin.normal.out visionfive2_fw_payload.img temp-dir/root/
sudo sync; sudo sync; sudo sync; sudo sync;
sudo umount temp-dir
Eject the SD card from your computer, insert it in your VisionFive 2 and power it up. The green LED should start blinking to indicate successful board power-up.
Plug the network cable in the Ethernet port that is next to the HDMI port. (The other port has DHCP-related issues with early firmware.)
ssh root@<IP_ADDRESS> (passwd: starfive)
Run the command cat /proc/mtd and you should have the following output:
dev: size erasesize name\nmtd0: 00020000 00001000 \"spl\"\nmtd1: 00300000 00001000 \"uboot\"\nmtd2: 00100000 00001000 \"data\"\nIf and only if the partition information given above matches with yours, update the spl and uboot partitions using the following commands:
flashcp -v u-boot-spl.bin.normal.out /dev/mtd0\nflashcp -v visionfive2_fw_payload.img /dev/mtd1\nThe board firmware has now been updated!
","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#current-things-that-are-wip","title":"Current things that are WIP","text":"A Rocky Linux image
","tags":["riscv","starfive","visionfive"]},{"location":"RISCV64/visionfive_2/#maintainers","title":"Maintainers","text":"There are several developers who are working on the RISC-V port of Rocky Linux in general, but following are all the maintainers who are supporting the VisionFive 2 SBC. These usernames are what they use on the Rocky Linux Mattermost chat.
dnf always claims to require a restart","text":""},{"location":"RPi/solutions/solutions/#symptom","title":"Symptom","text":"Even though the system has been restarted recently, e.g., after a Kernel update, dnf needs-restarting -r always returns with exit code 1.
# dnf needs-restarting -r\nCore libraries or services have been updated since boot-up:\n * dbus\n * dbus-daemon\n * glibc\n * linux-firmware\n * systemd\n\nReboot is required to fully utilize these updates.\nMore information: https://access.redhat.com/solutions/27943\nThis affects both Rocky Linux 8 and 9. However, a patch for 9.3 is to be released soon.
"},{"location":"RPi/solutions/solutions/#cause","title":"Cause","text":"The dnf plugin uses the mtime of /proc/1 which is set to start of epoch due to lack of RTC on Raspberry Pi. The correct system time is set later at boot once network connectivity is established and an NTP server is reachable. Compared to 1970, every package update is after the last reboot which causes the wrong result.
Until 9.3 is released, or if the system is still on 8.x, the patch can be manually applied to all versions.
# patch /usr/lib/python3.6/site-packages/dnf-plugins/needs_restarting.py <<EOF\n--- a/plugins/needs_restarting.py\n+++ b/plugins/needs_restarting.py\n@@ -34,6 +34,7 @@ import functools\n import os\n import re\n import stat\n+import time\n\n\n # For which package updates we should recommend a reboot\n@@ -199,7 +200,28 @@ class ProcessStart(object):\n\n @staticmethod\n def get_boot_time():\n- return int(os.stat('/proc/1').st_mtime)\n+ \"\"\"\n+ We have two sources from which to derive the boot time. These values vary\n+ depending on containerization, existence of a Real Time Clock, etc.\n+ For our purposes we want the latest derived value.\n+ - st_mtime of /proc/1\n+ Reflects the time the first process was run after booting\n+ This works for all known cases except machines without\n+ a RTC - they awake at the start of the epoch.\n+ - /proc/uptime\n+ Seconds field of /proc/uptime subtracted from the current time\n+ Works for machines without RTC iff the current time is reasonably correct.\n+ Does not work on containers which share their kernel with the\n+ host - there the host kernel uptime is returned\n+ \"\"\"\n+\n+ proc_1_boot_time = int(os.stat('/proc/1').st_mtime)\n+ if os.path.isfile('/proc/uptime'):\n+ with open('/proc/uptime', 'rb') as f:\n+ uptime = f.readline().strip().split()[0].strip()\n+ proc_uptime_boot_time = int(time.time() - float(uptime))\n+ return max(proc_1_boot_time, proc_uptime_boot_time)\n+ return proc_1_boot_time\n\n @staticmethod\n def get_sc_clk_tck():\n-- \n2.41.0\nEOF\nIt is advisable to version-lock the plugin version until it's fixed upstream. On 8.x, that might be the only solutions if the patch is not backported to 8.x upstream. Use at your own risk!
# dnf versionlock add python3-dnf-plugins-core\n* Sherif\n* Bryan\n* Pratham Patel\n* Pablo Greco\n* Alan Marshall\n* Brian Clemens\n* Neil Hanlon\nOriginally, Skip and Pablo built rpi image and kernel. Afterwards, Sherif began working with Pablo to build a generic arm kernel for more than just RPis. GenericArm image is being built with Empanadas, but not widely used. It should support Rpi as well as others.
As a rule, we cannot rely on EPEL dependencies, and will need to pull them into our build roots. We should work on/request tooling to aid in these operations--i.e., something to identify dependencies, and perform imports of them for us.
"},{"location":"events/meeting-notes/2023-10-20/#kernels","title":"Kernels","text":"Building 5.15 and 6.1 kernels in SIG/AltArch, but will be moving them to SIG/Kernel
Will also include kernel-mainline (6.5/6.6).
"},{"location":"events/meeting-notes/2023-10-20/#sbcs","title":"SBCs","text":"Recently, Bryan and Pratham began working with other SBCs like 3 Libre Computing boards, Orange Pi 5, Rock5b, Odroid purchased by RESF provided to several testers.
"},{"location":"events/meeting-notes/2023-10-20/#libre-boards","title":"Libre boards","text":"Pablo: * Need to separate kernel vs uboot. We are near to the end of the year, so we are very close to a new kernel LTS being cut which will probably be based on * re: uboot -- would like to stay as close to vanilla (Fedora) uboot as possible, but that is obviously difficult for every single board, practically. Ideally, we can build these as RPMs, just like \"normal\" uboot (this would also make composing images a lot easier, logistically speaking). Another option, if we have to, is to build specific binaries and provide them in a \"one-off\" repo to users as needed.
Sherif: * tool like arm-image-installer script to download the right uboot, image, etc, and put it into the disk at the right place. basically: make it pretty fool proof * like spi-tool (?) from Pine64 * Fedora and Debian are doing something like this * In general, we want to have the least amount of uboots required, whatever the case * try to port changes into a single generic uboot where possible * tl;dr - there are a lot of boards. can't please everyone
Pratham - questions on Kernels * was using elrepo kernels to test (mainline, mostly) * realized RHEL kernels are missing configs for booting these boards * built kernel.org kernel, and it boots all three libre boards and the rock5b * How to proceed from here? There are a lot of configs which need setting, e.g.. * Storytime! * we all use the same kernel.org tarballs -- without changes * Sherif and Pablo worked on changes to contribute to elrepo, they are very welcoming, in general. * The configs and specs are going to be--mostly, where the Kernel contributions can be * we should always be contributing back to elrepo, so that the entire community can benefit from the changes/features we add * We also begin to limit the amount of backports/changes we need to do over time * the current rocky LTS kernel is the same now as elrepo, due to the PR we've introduced * another example - HPC sig kernel * stripped down kernel for compute nodes, based on the Rocky base kernel with patches * openpatch :D * https://elrepo.org/bugs/view.php?id=1345 * We should document this and our policy on upstreaming work to ELRepo for Kernel changes. * tl;dr - base work on elrepo and make PRs there, then bring them into SIG/Kernel
"},{"location":"events/meeting-notes/2023-10-20/#generic-image","title":"Generic Image","text":"* Pablo - some boards look for grub binaries in a _highly_ specific location, and we need to make sure that we make a copy of those (links) into those locations\n * i.e., their uboots aren't looking for grubx64.efi in the right place\n* Neil - We can announce the availability of this more generally in our 9.3 / 8.9 releases coming in November.\n* We are looking for hardware which we can use to do these builds. We have some VMs currently, but they are not quite powerful enough.\n* OSU OSL should have some Lenovo eMags for us, at some point.\n * Neil to reach out to Ramareth\n * Neil to reach out to Aaron from Ampere\n* If we can't get anything from OSU, let's ping SolidRun or Ampere to see if they can do anything for us and figure it ourselves.\n* right now, it takes 2+ days to build gcc in qemu\n* there have been a lot of good changes in qemu to add more support but we should try and do native builds if possible.\n* Neil - Investigate what and how much riscv hardware we need.. and where we'll host it\n* https://www.crowdsupply.com/milk-v/milk-v-pioneer\n* Images should be generic so as to be able to be installed on any board, where possible.\n * uboot can live on SPI or external flash\n * We need to help document this for our users and have guides on how to get the SBCs working. This is a big pain point for many SBC users as there is so much variation.\n * To this end, we should investigate some tooling to aid in writing images for boards which will boot on the first try.\n* Uboot should similarly be generic and work for all boards, insofar as it is practical to do so.\n * Some boards this doesn't make sense for, e.g., ones that have uboot from 2014 + hundreds of patches, however, these are few and far between. For these, we can package them as RPMs and provide them (see note below re: licensing)\n* We will wait for the next Kernel.org LTS to be cut, as that should have all the changes for the boards we're talking about.\n* We will engage with our upstreams (Fedora, ELRepo, etc) for changes we make with the Kernel SIG for AltArch/SBC support.\n * This necessitates participating in SIG/Kernel to represent our needs in these kernels.\n* We should strive to perform native builds when possible, but recognize that emulation is a necessary evil.\nuboot and other licensing
We need to ensure that we are careful about the licensing of softwares we wish to include in the SIG distribution.
"},{"location":"events/meeting-notes/2023-10-20/#action-items","title":"Action items:","text":"arm-image-installer script/tool for helping write disk images for specific boards - Sherif (?)* Sherif\n* Bryan\n* Pablo Greco\n* Neil Hanlon\n* Skip Grube\narm-image-installer script/tool for helping write disk images for specific boards - Sherif (?)arm-image-installer script/tool for helping write disk images for specific boards - Sherif (?)* Images should be generic so as to be able to be installed on any board, where possible.\n * uboot can live on SPI or external flash\n * We need to help document this for our users and have guides on how to get the SBCs working. This is a big pain point for many SBC users as there is so much variation.\n * To this end, we should investigate some tooling to aid in writing images for boards which will boot on the first try.\n* Uboot should similarly be generic and work for all boards, insofar as it is practical to do so.\n * Some boards this doesn't make sense for, e.g., ones that have uboot from 2014 + hundreds of patches, however, these are few and far between. For these, we can package them as RPMs and provide them (see note below re: licensing)\n* We will wait for the next Kernel.org LTS to be cut, as that should have all the changes for the boards we're talking about.\n* We will engage with our upstreams (Fedora, ELRepo, etc) for changes we make with the Kernel SIG for AltArch/SBC support.\n * This necessitates participating in SIG/Kernel to represent our needs in these kernels.\n* We should strive to perform native builds when possible, but recognize that emulation is a necessary evil.\nuboot and other licensing
We need to ensure that we are careful about the licensing of softwares we wish to include in the SIG distribution.
"},{"location":"events/meeting-notes/2024-01-12/","title":"SIG/AltArch meeting 2024-01-12","text":""},{"location":"events/meeting-notes/2024-01-12/#attendees","title":"Attendees:","text":"* Sherif\n* Bryan\n* Neil Hanlon\n* Skip Grube\n* Jason Rodriguez\n* Jonathan Maple\narm-image-installer script/tool for helping write disk images for specific boards - Sherif (?)* Images should be generic so as to be able to be installed on any board, where possible.\n * uboot can live on SPI or external flash\n * We need to help document this for our users and have guides on how to get the SBCs working. This is a big pain point for many SBC users as there is so much variation.\n * To this end, we should investigate some tooling to aid in writing images for boards which will boot on the first try.\n* Uboot should similarly be generic and work for all boards, insofar as it is practical to do so.\n * Some boards this doesn't make sense for, e.g., ones that have uboot from 2014 + hundreds of patches, however, these are few and far between. For these, we can package them as RPMs and provide them (see note below re: licensing)\n* We will wait for the next Kernel.org LTS to be cut, as that should have all the changes for the boards we're talking about.\n* We will engage with our upstreams (Fedora, ELRepo, etc) for changes we make with the Kernel SIG for AltArch/SBC support.\n * This necessitates participating in SIG/Kernel to represent our needs in these kernels.\n* We should strive to perform native builds when possible, but recognize that emulation is a necessary evil.\nuboot and other licensing
We need to ensure that we are careful about the licensing of softwares we wish to include in the SIG distribution.
"},{"location":"events/meeting-notes/2024-01-26/","title":"SIG/AltArch meeting 2024-01-26","text":""},{"location":"events/meeting-notes/2024-01-26/#attendees","title":"Attendees","text":"https://git.resf.org/sig_altarch/meta/issues/4 - Jan 2024 uboot - Closed
"},{"location":"events/meeting-notes/2024-01-26/#open-floor","title":"Open Floor","text":"--# diff config-6.1.0-rpi7-rpi-2712 config-6.1.0-rpi7-rpi-v8\n31c31\n< CONFIG_LOCALVERSION=\"-v8-16k\"\n---\n> CONFIG_LOCALVERSION=\"-v8\"\n270,275c270,275\n< CONFIG_ARM64_PAGE_SHIFT=14\n< CONFIG_ARM64_CONT_PTE_SHIFT=7\n< CONFIG_ARM64_CONT_PMD_SHIFT=5\n< CONFIG_ARCH_MMAP_RND_BITS_MIN=16\n< CONFIG_ARCH_MMAP_RND_BITS_MAX=30\n< CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=9\n---\n> CONFIG_ARM64_PAGE_SHIFT=12\n> CONFIG_ARM64_CONT_PTE_SHIFT=4\n> CONFIG_ARM64_CONT_PMD_SHIFT=4\n> CONFIG_ARCH_MMAP_RND_BITS_MIN=18\n> CONFIG_ARCH_MMAP_RND_BITS_MAX=24\n> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11\n391,392c391,392\n< # CONFIG_ARM64_4K_PAGES is not set\n< CONFIG_ARM64_16K_PAGES=y\n---\n> CONFIG_ARM64_4K_PAGES=y\n> # CONFIG_ARM64_16K_PAGES is not set\n394,395c394\n< # CONFIG_ARM64_VA_BITS_36 is not set\n< CONFIG_ARM64_VA_BITS_47=y\n---\n> CONFIG_ARM64_VA_BITS_39=y\n397c396\n< CONFIG_ARM64_VA_BITS=47\n---\n> CONFIG_ARM64_VA_BITS=39\n422c421\n< CONFIG_ARCH_FORCE_MAX_ORDER=12\n---\n> CONFIG_ARCH_FORCE_MAX_ORDER=11\n889a889\n> CONFIG_ARCH_WANTS_THP_SWAP=y\n| Model | Image | Status | |---------------|---------------------------------------------------| | In early phases of discovery. | | |
"}]}