ROCKPro64 Hardware Tweaks - Revision history

Dsimic: /* Enabling PCIe 2.0 */ Expanded the warning a bit

2023-10-24T10:53:45Z

Enabling PCIe 2.0: Expanded the warning a bit

← Older revision		Revision as of 10:53, 24 October 2023
Line 1:		Line 1:
	== Enabling PCIe 2.0 ==		== Enabling PCIe 2.0 ==
	{{Warning\|The downgrade to Gen1 speed came [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207 straight from Rockchip]], as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399's internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains.}}		{{Warning\|The downgrade to Gen1 speed came [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207 straight from Rockchip]], as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399's internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains, unless using specific PCI Express hardware. See also the notes in [[Pinebook Pro Hardware Accessory Compatibility#NVMe SSD drives]].}}

	By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.		By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.

Dsimic: /* Enabling PCIe 2.0 */ Better wording

2023-10-24T10:00:02Z

Enabling PCIe 2.0: Better wording

← Older revision		Revision as of 10:00, 24 October 2023
Line 1:		Line 1:
	== Enabling PCIe 2.0 ==		== Enabling PCIe 2.0 ==
	{{Warning\|The downgrade to Gen1 speed came [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207 straight from Rockchip]], as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause instability ~~issues~~ or data corruption under certain circumstances. Also, the limitations of the RK3399's internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains.}}		{{Warning\|The downgrade to Gen1 speed came [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207 straight from Rockchip]], as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399's internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains.}}

	By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.		By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.

Dsimic: /* Overclocking (and undervolting) */ Ditto

2023-10-24T09:59:04Z

Overclocking (and undervolting): Ditto

← Older revision		Revision as of 09:59, 24 October 2023
Line 34:		Line 34:

	== Overclocking (and undervolting) ==		== Overclocking (and undervolting) ==
	{{Warning\|Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption. There is even the possibility of damaging your equipment.}}		{{Warning\|Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption under certain circumstances. There is even the possibility of damaging your equipment permanently.}}

	The RK3399 can be overclocked. See here for details: [[Overclocking#RK3399-based devices]].		The RK3399 can be overclocked. See here for details: [[Overclocking#RK3399-based devices]].
	By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file.		By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file.

	Below is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable.		Below is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable.
	The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz.		The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz.

Dsimic: /* Stabilizing the system (underclocking the RAM) */ Clarified a bit

2023-10-24T09:56:36Z

Stabilizing the system (underclocking the RAM): Clarified a bit

← Older revision		Revision as of 09:56, 24 October 2023
Line 217:		Line 217:

	== Stabilizing the system (underclocking the RAM) ==		== Stabilizing the system (underclocking the RAM) ==
	{{Warning\|As pointed out by CrystalGamma, "normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I'd be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed". In other words, "the risk is refreshes coming to late, though it's probably within tolerance with this little of a frequency diff".}}		{{Warning\|As pointed out by CrystalGamma, "normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I'd be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed". In other words, "the risk is refreshes coming to late, though it's probably within tolerance with this little of a frequency diff".<br /><br />

			To put it simply, the suggested changes to DRAM configuration may actually cause system instability or data corruption under certain circumstances.}}

	By default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be "fixed" by starting the build again and hoping gcc doesn't crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz. The PKGBUILD for this is available here: https://aur.archlinux.org/packages/uboot-rockpro64-foss		By default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be "fixed" by starting the build again and hoping gcc doesn't crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz. The PKGBUILD for this is available here: https://aur.archlinux.org/packages/uboot-rockpro64-foss

Dsimic: /* Getting WiFi working (new WiFi module) */ Ditto

2023-10-24T09:53:50Z

Getting WiFi working (new WiFi module): Ditto

← Older revision		Revision as of 09:53, 24 October 2023
Line 148:		Line 148:

	== Getting WiFi working (new WiFi module) ==		== Getting WiFi working (new WiFi module) ==
	{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository. Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of ~~performing~~ local changes.}}		{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository. Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of suggesting local changes to be performed.}}

	Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.		Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.

Dsimic: /* Overclocking (and undervolting) */ Better wording

2023-10-24T09:52:48Z

Overclocking (and undervolting): Better wording

← Older revision		Revision as of 09:52, 24 October 2023
Line 34:		Line 34:

	== Overclocking (and undervolting) ==		== Overclocking (and undervolting) ==
	{{Warning\|Please note that changing the maximum operating frequency or the supply voltage may cause system instability. There is even the possibility of damaging your equipment ~~by overclocking~~.}}		{{Warning\|Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption. There is even the possibility of damaging your equipment.}}

	The RK3399 can be overclocked. See here for details: [[Overclocking#RK3399-based devices]].		The RK3399 can be overclocked. See here for details: [[Overclocking#RK3399-based devices]].

Dsimic: /* Getting WiFi working (new WiFi module) */ Clarified further

2023-10-24T09:46:56Z

Getting WiFi working (new WiFi module): Clarified further

← Older revision		Revision as of 09:46, 24 October 2023
Line 148:		Line 148:

	== Getting WiFi working (new WiFi module) ==		== Getting WiFi working (new WiFi module) ==
	{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository.}}		{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository. Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of performing local changes.}}

	Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.		Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.

Dsimic: /* Getting wifi working ("new" wifi module) */ Minor cleanups

2023-10-24T09:14:35Z

Getting wifi working ("new" wifi module): Minor cleanups

← Older revision		Revision as of 09:14, 24 October 2023
Line 147:		Line 147:
	APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil		APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil

	== Getting ~~wifi~~ working ("new~~" wifi~~ module) ==		== Getting WiFi working (new WiFi module) ==
	{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository.}}		{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository.}}

Line 155:		Line 155:
	sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt		sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt

	Then, reboot and ~~Wi-Fi~~ should start working.		Then, reboot and WiFi should start working. Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635&pid=117061#pid117061
	Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635&pid=117061#pid117061
	However, on a 5GHz network with <code>wireless-regdb</code> installed and the regulatory domain set to 'US', the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This "can" be resolved by setting the regulator domain to 'GB' or 'CN', but this isn't a solution for you if you are in the USA, for instance. There are various other <code>brcmfmac43455-sdio.txt</code> files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default <code>brcmfmac43455-sdio.AW-CM256SM.txt</code> file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to 'US').		However, on a 5GHz network with <code>wireless-regdb</code> installed and the regulatory domain set to 'US', the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This "can" be resolved by setting the regulator domain to 'GB' or 'CN', but this isn't a solution for you if you are in the USA, for instance. There are various other <code>brcmfmac43455-sdio.txt</code> files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default <code>brcmfmac43455-sdio.AW-CM256SM.txt</code> file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to 'US').

Dsimic: /* Getting wifi working ("new" wifi module) */ Added a warning

2023-10-24T09:13:17Z

Getting wifi working ("new" wifi module): Added a warning

← Older revision		Revision as of 09:13, 24 October 2023
Line 148:		Line 148:

	== Getting wifi working ("new" wifi module) ==		== Getting wifi working ("new" wifi module) ==
			{{Warning\|The information presented in this section may be obsolete because of [[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6 this commit]] in the linux-firmware upstream repository.}}

	Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.		Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.
	You can copy this file to the new name (that the driver looks for) with the following commands:		You can copy this file to the new name (that the driver looks for) with the following commands:

Dsimic: /* Getting wifi working ("new" wifi module) */ Minor cleanup

2023-10-24T06:45:26Z

Getting wifi working ("new" wifi module): Minor cleanup

← Older revision		Revision as of 06:45, 24 October 2023
Line 148:		Line 148:

	== Getting wifi working ("new" wifi module) ==		== Getting wifi working ("new" wifi module) ==
	~~ManjaroARM~~ and ~~ArchLinuxARM~~ (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.		Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.
	You can copy this file to the new name (that the driver looks for) with the following commands:		You can copy this file to the new name (that the driver looks for) with the following commands:
	cd /usr/lib/firmware/brcm/		cd /usr/lib/firmware/brcm/