(Add cpufreq governor configuration (originally written by davidlt for the vf2 page)) |
(Don't use first person) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 5: | Line 5: | ||
If your machine is listed in the [[#Machine-specific instructions]] section below, make sure you check out the corresponding page first, as it might contain important information that (partially or completely) supersedes what's written here. | If your machine is listed in the [[#Machine-specific instructions]] section below, make sure you check out the corresponding page first, as it might contain important information that (partially or completely) supersedes what's written here. | ||
== Downloading | == Media preparation == | ||
=== Downloading the disk image === | |||
Disk images can be obtained from: | Disk images can be obtained from: | ||
Line 19: | Line 21: | ||
A matching <code>IMAGE.raw.xz.sha256</code> file is also provided: this allows you to validate the integrity of your download. | A matching <code>IMAGE.raw.xz.sha256</code> file is also provided: this allows you to validate the integrity of your download. | ||
== Writing the disk image to the target media == | === Writing the disk image to the target media === | ||
The disk image is intended to work regardless of the type of media it's written to: SD cards, USB sticks, NVMe and SATA drives are all known to work. NVMe is preferred, if available on your machine, because it performs the best, but you can choose whatever is more suitable to you. SD cards, for example, are great when you want to test a disk image without affecting your existing installation. | The disk image is intended to work regardless of the type of media it's written to: SD cards, USB sticks, NVMe and SATA drives are all known to work. NVMe is preferred, if available on your machine, because it performs the best, but you can choose whatever is more suitable to you. SD cards, for example, are great when you want to test a disk image without affecting your existing installation. | ||
Line 40: | Line 42: | ||
[https://etcher.balena.io/ balenaEtcher] is another popular option. It's a user-friendly GUI that should make it a lot harder to mess things up. | [https://etcher.balena.io/ balenaEtcher] is another popular option. It's a user-friendly GUI that should make it a lot harder to mess things up. | ||
== Serial console access == | |||
While <code>ssh</code> is likely going to be the primary way you'll interact with the machine, it's useful to have serial console access as a fallback. Moreover, it is '''required''' for the initial setup. | |||
The process of connecting the USB to serial adapter is machine-specific and can't be documented in a generic fashion. | |||
First of all, make sure your user is in the <code>dialup</code> group: | |||
<pre> | |||
$ sudo usermod -a -G dialout $(whoami) | |||
</pre> | |||
This is necessary to access the serial console. Log out and back in for the change to take effect. | |||
Now plug the USB to serial adapter into your computer. If you only have one such adapters connected, it should show up as <code>/dev/ttyUSB0</code>. | |||
Create a configuration file for <code>minicom</code>, with the name you like, for example <code>~/.minirc.RISCV</code>. The contents should look like this: | |||
<pre> | |||
pu port /dev/ttyUSB0 | |||
pu baudrate 115200 | |||
pu bits 8 | |||
pu parity N | |||
pu stopbits 1 | |||
pu rtscts No | |||
</pre> | |||
You will now be able to connect to the serial console by running: | |||
<pre> | |||
$ minicom RISCV | |||
</pre> | |||
For added reliability, you can use a stable device name in the configuration file. For example: | |||
<pre> | |||
$ ls -l /dev/serial/by-id/* | |||
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0 | |||
</pre> | |||
This output indicates that you should replace <code>/dev/ttyUSB0</code> with <code>/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0</code> in the configuration file. | |||
== First boot == | == First boot == |
Latest revision as of 21:11, 30 January 2025
Generic instructions
The following installation steps are applicable to most hardware.
If your machine is listed in the #Machine-specific instructions section below, make sure you check out the corresponding page first, as it might contain important information that (partially or completely) supersedes what's written here.
Media preparation
Downloading the disk image
Disk images can be obtained from:
As of this writing, the most recent disk image is:
The file you've just downloaded will be referred to as IMAGE.raw.xz
below.
A matching IMAGE.raw.xz.sha256
file is also provided: this allows you to validate the integrity of your download.
Writing the disk image to the target media
The disk image is intended to work regardless of the type of media it's written to: SD cards, USB sticks, NVMe and SATA drives are all known to work. NVMe is preferred, if available on your machine, because it performs the best, but you can choose whatever is more suitable to you. SD cards, for example, are great when you want to test a disk image without affecting your existing installation.
The disk image comes compressed, so the first step after downloading it is to uncompress it:
$ unxz IMAGE.raw.xz
The compressed IMAGE.raw.xz
file will be replaced by the uncompressed IMAGE.raw
file. The latter is the one that can be written to the target media.
There are several tools that can be used for writing the disk image. dd
is perhaps the most common option:
$ sudo dd iflag=fullblock oflag=direct status=progress bs=4M if=IMAGE.raw of=/dev/TARGET
Replace /dev/TARGET
with the name of the actual target device. Please be extremely careful and ensure that you're using the correct name here: if you get it wrong, you risk destroying your current OS.
balenaEtcher is another popular option. It's a user-friendly GUI that should make it a lot harder to mess things up.
Serial console access
While ssh
is likely going to be the primary way you'll interact with the machine, it's useful to have serial console access as a fallback. Moreover, it is required for the initial setup.
The process of connecting the USB to serial adapter is machine-specific and can't be documented in a generic fashion.
First of all, make sure your user is in the dialup
group:
$ sudo usermod -a -G dialout $(whoami)
This is necessary to access the serial console. Log out and back in for the change to take effect.
Now plug the USB to serial adapter into your computer. If you only have one such adapters connected, it should show up as /dev/ttyUSB0
.
Create a configuration file for minicom
, with the name you like, for example ~/.minirc.RISCV
. The contents should look like this:
pu port /dev/ttyUSB0 pu baudrate 115200 pu bits 8 pu parity N pu stopbits 1 pu rtscts No
You will now be able to connect to the serial console by running:
$ minicom RISCV
For added reliability, you can use a stable device name in the configuration file. For example:
$ ls -l /dev/serial/by-id/* /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0
This output indicates that you should replace /dev/ttyUSB0
with /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
in the configuration file.
First boot
Once the disk image has been written to the target media, you can pop that into your machine and power it on.
The process of getting the firmware to boot from the media is machine-specific and can't be documented in a generic fashion. It usually helps if only one media is connected to the machine at any given time.
Assuming everything is fine, after a few seconds you should see the usual Linux boot messages scroll by on the serial console.
The boot might appear to hang after a while. Please be patient and give it some time; eventually, initial-setup
should show up. This is what it will look like:
================================================================================ ================================================================================ 1) [ ] Language settings 2) [x] Time settings (Language is not set.) (America/New_York timezone) 3) [x] Network configuration 4) [!] Root password (Connected: enp1s0) (Root account is disabled) 5) [!] User creation (No user will be created) Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to refresh]:
While all items should be functional, it is mandatory to complete either 4) [!] Root password
or 5) [!] User creation
. You will not be able to log into the machine at all otherwise.
Post-installation tasks
Enable the performance CPU governor
The default CPU governor is schedutils
, which scales the CPU frequency dynamically. If you want to squeeze every last bit of performance out of your machine, you might want to switch to the performance
CPU governor. To do so, simply run:
$ sudo grubby --update-kernel=ALL --args=cpufreq.default_governor=performance
A reboot is necessary for the change to take effect.
Machine-specific instructions
While the information above is generally applicable, some machines require additional or even completely different steps.