1# ____ ___ ____ ____ __ __ __ __ _____ _______ ____
2# | _ \|_ _/ ___| / ___| \ \ / / | \/ |_ _\ \/ / ____| _ \
3# | |_) || |\___ \| | ____\ \ / / | |\/| || | \ /| _| | |_) |
4# | _ < | | ___) | |__|_____\ V / | | | || | / \| |___| _ <
5# |_| \_\___|____/ \____| \_/ |_| |_|___/_/\_\_____|_| \_\
1 _____ _ _____ __ _ _ __
2 / ____| | | __ \ / /| || | / /
3| (___ | |_ __ _ _ __| |__) | __ ___ / /_| || |_ / /
4 \___ \| __/ _` | '__| ___/ '__/ _ \| '_ \__ _| / /
5 ____) | || (_| | | | | | | | (_) | (_) | | | / /
6|_____/ \__\__,_|_| |_| |_| \___/ \___/ |_| /_/
7
8
9 _ _ ____
10 /\ | | | | / __ \
11 / \ | |_ __ | |__ __ _ ______| | | |_ __ ___
12 / /\ \ | | '_ \| '_ \ / _` |______| | | | '_ \ / _ \
13 / ____ \| | |_) | | | | (_| | | |__| | | | | __/
14/_/ \_\_| .__/|_| |_|\__,_| \____/|_| |_|\___|
15 | |
16 |_|
Adventures with Pine64 Alpha-One (StarPro64) #
Far be it, anyone confuse our operation with being a spendthrift, but due to the age of some of the machines we run in our operation, the jump to AI lightspeed has come at a snail’s pace. We have yet had the means nor the requirement to implement anything like Kubuernetes on our systems, but with the release of Pine64’s Alpha-One, we have dedicated the resources necessary to handle the AI matter.
For those who are unfamiliar with the Alpha-One, it is advertised as being a personal AI dedicated agent, but it might as well be synonymous Pine64’s StarPro64, as the hardware of the two are physically identical. The only distinguishing feature that differentiates the Alpha-One from the StarPro64 physically is the milled aluminum enclosure, and the provision of a 64GB EMMC module. The octo-core Risc-V processor of the StarPro64 has a tendency (or flaw) of generating a substantial amount of heat. Without some facsimile of a heat-sink, the processor will simply shut itself off to prevent damage once powered on and warmed up. While you can purchase heat-sinks and fans to mitigate over heating, the milled aluminum enclosure of the Alpha-One was designed specifically to resolve this issue through an application of the laws of thermodynamics, distributing the generated heat across the entirety of the aluminum enclosure. Thus, ensuring the CPU will never reach critical temperatures, and can be utilized to it’s fullest.
Intro #
For this dive into the world of Risc-V processors we will be using the Alpha-One AI agent to resolve a noisy console, and to explore how to boot into an SD-card through U-Boot.
Silencing Verbose Console Chatter #
Have you tried to login to a system, but experience difficulty because error messages are continuously being dumped to
the console, and the messages are interrupting any command you try to execute in the terminal? Your system does this for
a reason, which is to notify the user of critical errors effecting how the system provides services. So, the messages,
themselves are important, and deserve recognition by whoever is administrating the particular system. Afterwards,
modification of the system settings should take place as to prevent these messages from interrupting the user while the
issue is troubleshot. This modification is performed by using the sysctl command, which handles kernel level settings
for the system during runtime.
Understanding kernel.printk #
For lack of knowledge and to provide some entertainment, we will say that the sysctl setting kernel.printk stands
for "kernel print kinky", and that the problem we are experiencing is that the kernel is printing error messages too
kinky for use. (intentionally ridiculous...) The value of this configuration variable is structured as a set of four
space or tab separated integers representing the level of verbosity for four categories of error messages. They are
abbreviated as CUR, DEF, MIN, and BTDEF. The key below provides the definition for these abbreviations:
| Abbreviation | Meaning |
|---|---|
| CUR | Current Severity Level |
| DEF | Default Severity Level |
| MIN | Minimal Allowable Current Level |
| BTDEF | Default Severity Level during Boot time |
These settings vary slightly across Linux distributions, but remain relatively similar as far as purpose goes. The key
is understanding the higher the integer, the higher the verbosity level of the error messages. So, to reduce chatter in
your console, you will need to lower the values of CUR and BTDEF. The table below shows the relationship of these
categories to their settings, denoting their default value as "D", and the new modified setting as "M". Both "X" and "x"
are used to demonstrate that category CUR and BTDEF are inclusive, and setting a log level value entails all the
lower values below them. The "X" denoting values that are both default and newly modified, and "x" for only newly
modified.
Here is the key to the table, represented in a tably itself.
| Symbol | Meaning |
|---|---|
| X | Inclusively enabled in both Default and Modified settings |
| x | Inclusively enabled by Modified settings |
| M | Modified Setting |
| D | Default Setting |
Now here is the table referenced above to apply the key too.
| Num | Description | CUR | DEF | MIN | BTDEF |
|---|---|---|---|---|---|
| 0 | Emergency | X | X | ||
| 1 | Alert | X | D | X | |
| 2 | Critical | X | X | ||
| 3 | Error | M | M | ||
| 4 | Warning | x | D | x | |
| 5 | Notice | x | x | ||
| 6 | Informational | D | D | ||
| 7 | Debug |
Making changes #
To set the values for kernel.printk and have the change take effect immediately we use the -w flag with sysctl. To
have the changes made permanently, which is not desired in this instance, we would need to add the key / value pair to
the /etc/sysctl.conf or equivalent file. So, in summary the command to quiet the undesired console chatter, would be
sudo sysctl -w kernel.printk="2 4 1 7". Which should be copied and pasted into your terminal to make applying the
modification easier.
Booting from the SD-Card in U-Boot #
U-Boot is the "Universal Bootloader", and it’s purpose is to initialize hardware and prepare the device to run the operating system’s kernel. It performs a similar function as bios, but is not a replacement for bios. It is primarily used in embeded devices, but can be run on nearly about everything. For those who are accustomed to working with Grub, U-Boot is a completely different animal, and provides many welcomed features not available in other boot loaders. U-Boot is considerable more complex than previous implemented boot loaders as well, and uses a different terminology which might be a little confusing to first time users.
A more thorough overview is overdue on the wiki, as what is covered here is just enough to provide some guidance on how to go from the u-boot prompt to booting into your SD-Card on the Alpha-One.
Finding your way #
Before booting into your SD-Card, you need to familiarize yourself with your working environment, particularly the name of the device you want to boot into, because this will be required to perform the boot.
- The first thing you should do from the U-Boot prompt is review the environment variables that control the boot
process of your system. This can be done with the
printenvcommand. - Then you will probably want to review the hardware of the device you are booting -
dm treeordm uclass. - SD-Cards and eMMC devices can be listed with
mmc list. - Just for future reference, USB devices can be listed with
usb startand thenusb dev.
Booting into your SD-Card. #
Now that you have the name of the device you want to boot into, and are aware of how your system boots with default settings, it is time to use that information to perform the boot.
Since the local eMMC device will be designated as "0", it is reasonably safe to say the SD-card will be designated as "1".
- So, set the U-Boot to use device "1" -
mmc dev 1 - Then perform the boot with:
1# Rescan the media (sdcard) for a bootable partition & boot
2bootflow scan -lb
[!warning] Performing boot in the manner described in this section will not result in a successful boot. Rather, U-Boot will be unable to locate the sector to boot from.
On our device, the Alpha-One / StarPro64, after executing the above command, we were provided with a menu asking us to select either the "normal kernel" or the "Recovery kernel". From which, we selected the desired option.
We do know that this is not always the case for every device, because the instructions for U-Boot includes an additional command we never found it necessary to use.
1bootflow boot # Boots the first valid flow
So, whether you use it or not, is up to how your system is configured.
Booting from U-Boot from the USB #
You can also use a USB storage device, or "thumb drive", to boot from in U-Boot, all that is needed is to take a different approach.
The key difference to booting from USB versus booting from SD-card, is rather than use the mmc command, you use the
usb command, and you must start the USB service first with usb start. Then you can set your device by using usb dev ${N}. Where ${N} represents the usb device number you want to boot from. From there you simply run bootflow scan -lb and boot the system.
Summary #
So in this episode of the "Risc-V Mixer" we discussed silencing system messages to make the console usable with sudo sysctl -w kernel.printk="2 4 1 7", and booting your device from both an SD-Card or a USB storage device with
mmc dev 1 or usb start then usb dev 01 and running bootflow scan -lb.