ROC-RK3328-CC | libre computer board *

do over

how to create an installer

diskutil list // list all images

sudo diskutil unmountDisk /dev/diskX  //fillin X with our drive 
sudo dd if=/dev/zero of=/dev/rdiskX bs=1m status=progress //erase fill card with all 0's

sudo diskutil unmountDisk /dev/diskX  //change X
sudo dd if=ubuntu-22.04.3-preinstalled-server-arm64+roc-rk3328-cc.img of=/dev/rdiskX bs=1m status=progress // change X - flash new image


sync // run command

sudo diskutil eject /dev/diskX // change X eject disk

stick it in and boot from it!!z

It sounds like the new microSD card is working better, which is great news! Yes, if this new card is indeed booting up without issues, you would need to reapply any changes or configurations that you previously made to the old microSD card to this new one. Here’s a summary of what you might need to redo:

Changes to Reapply to the New MicroSD Card

1. System Configuration Changes:

• SSH Configuration: If you made changes like adding authorized keys for SSH or modifying /etc/ssh/sshd_config, you’ll need to redo those to ensure SSH access works properly.

• User Setup: Recreate any users you added previously, such as additional admin users and guest users. You can also set their passwords using:

sudo passwd username

• Sudo Privileges: If you gave certain users sudo privileges, you’ll need to add them back to the sudoers file or sudo group.

2. Disk Setup for USB Boot:

• If your goal is still to boot from an external USB drive, you’ll need to redo the partitioning and formatting of the USB drive, as well as copy the root filesystem from the microSD card to the USB drive:

• Partition and Format the USB: Set up the partitions on the USB drive (sda1 for EFI and sda2 for root).

• Copy Filesystem: Use rsync to copy the root filesystem from the microSD to the USB drive:

sudo rsync -axHAWXS –numeric-ids –info=progress2 /mnt/sdcard/ /mnt/external/

• GRUB Configuration: Set up GRUB on the external drive as we did before:

• Mount the EFI partition:

sudo mount /dev/sda1 /mnt/external/boot/efi

• Install GRUB:

sudo grub-install –target=arm64-efi –boot-directory=/mnt/external/boot –efi-directory=/mnt/external/boot/efi /dev/sda

• Update GRUB Configuration:

sudo grub-mkconfig -o /mnt/external/boot/grub/grub.cfg

• Manual Boot Setup (Optional): If the USB drive still needs some manual setup in U-Boot, you will need to attempt to access the U-Boot prompt during startup and configure it to prioritize USB.

3. Packages and Tools:

• Reinstall any necessary packages that you installed previously:

sudo apt-get update

sudo apt-get install u-boot-tools device-tree-compiler

• Install any additional utilities or tools that you were using.

4. Fan Setup and GPIO Pins:

• If the fan is part of your setup, ensure it is reconnected to the correct GPIO pins for cooling.

To Speed Up the Reconfiguration

• Create a Script: If you need to replicate these changes across multiple microSD cards or set them up again, consider creating a bash script to automate as much of the process as possible.

• Take Notes: Documenting the exact steps you took will be helpful in case you need to do this again.

It’s good to hear that the new microSD card seems to have resolved some issues—it’s possible the previous card or image was corrupted or simply not functioning as expected. Let me know if you need help with any of these reconfigurations or creating a script to make the setup easier!

Install Ubunut Image on ROC

It looks like you’re trying to flash an Ubuntu image onto your ROC-RK3328-CC device, but you’re running into some issues. Let’s use the correct process to write the image to your flash drive. Below, I’ll guide you step by step on how to properly execute this on a macOS system, since your device path (disk18s1) looks like it’s from macOS.

Step 1: Unmount the Flash Drive

First, you’ll need to unmount the flash drive to prevent macOS from accessing it during the writing process. This is important because dd will need full access to the drive.

1. List All Drives:

Run the following command to list all connected drives and confirm the correct device:

diskutil list

You should see something like /dev/disk18 with partitions disk18s1, disk18s2, etc.

2. Unmount the Drive:

Unmount the drive (disk18), but do not eject it:

diskutil unmountDisk /dev/disk18

Step 2: Write the Image Using dd

Now that the drive is unmounted, you can use the dd command to write the image.

1. Navigate to the Image File Location:

Go to the directory where your image is located:

cd /Users/spiffy/Desktop

2. Use dd to Write the Image:

Use the dd command to write the image to your flash drive. Note that you need to write to the whole disk (/dev/disk18), not a specific partition (/dev/disk18s1):

sudo dd if=ubuntu-22.04.3-preinstalled-server-arm64+roc-rk3328-cc.img of=/dev/rdisk18 bs=1m status=progress

Explanation:

• sudo: Grants the necessary permissions to write to the device.

• if=ubuntu-22.04.3-preinstalled-server-arm64+roc-rk3328-cc.img: The input file, which is your Ubuntu image.

• of=/dev/rdisk18: The output file is the raw disk (rdisk18). Using r (rdisk) can make the process faster, as it accesses the disk in raw mode.

• bs=1m: The block size is set to 1 megabyte for efficiency.

• status=progress: Displays progress while writing the image.

Note: Make absolutely sure that you are writing to the correct disk (/dev/rdisk18). Writing to the wrong disk can wipe other drives or partitions.

Step 3: Eject the Flash Drive

Once the process is complete, you need to eject the flash drive properly:

diskutil eject /dev/disk18

Additional Notes

• Speed: Writing an image with dd can be slow, depending on the speed of the USB port and the flash drive. Using rdisk can help improve performance.

• Permissions: sudo is required because writing directly to a disk involves altering system-level hardware.

Summary of Commands

1. Unmount the Flash Drive:

diskutil unmountDisk /dev/disk18

2. Write the Image:

sudo dd if=/Users/spiffy/Desktop/ubuntu-22.04.3-preinstalled-server-arm64+roc-rk3328-cc.img of=/dev/rdisk18 bs=1m status=progress

3. Eject the Flash Drive:

diskutil eject /dev/disk18

This should allow you to successfully write the image onto your flash drive, which you can then use to boot your ROC-RK3328-CC device.

OpenSSH Server

Note: This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.

OpenSSH is a powerful collection of tools for remotely controlling networked computers and transferring data between them. Here we’ll describe some of the configuration settings possible with the OpenSSH server application and how to change them on your Ubuntu system.

OpenSSH is a freely available version of the Secure Shell (SSH) protocol family of tools. Traditional tools, such as telnet or rcp, are insecure and transmit the user’s password in cleartext when used. OpenSSH provides a server daemon and client tools to facilitate secure, encrypted, remote control and file transfer operations, effectively replacing the legacy tools.

The OpenSSH server component, sshd, listens continuously for client connections from any of the client tools. When a connection request occurs, sshd sets up the correct connection depending on the type of client tool connecting. For example, if the remote computer is connecting with the SSH client application, the OpenSSH server sets up a remote control session after authentication. If a remote user connects to an OpenSSH server with scp, the OpenSSH server daemon initiates a secure copy of files between the server and client after authentication.

OpenSSH can use many authentication methods, including plain password, public key, and Kerberos tickets.

Install OpenSSH

To install the OpenSSH client applications on your Ubuntu system, use this command at a terminal prompt:

sudo apt install openssh-client

To install the OpenSSH server application, and related support files, use this command at a terminal prompt:

sudo apt install openssh-server

Configure OpenSSH

To configure the default behavior of the OpenSSH server application, sshd, edit the file /etc/ssh/sshd_config. For information about the configuration directives used in this file, refer to the online manpage or run man sshd_config at a terminal prompt.

There are many directives in the sshd configuration file, which control things like communication settings and authentication modes. The following are examples of configuration directives that can be changed by editing the /etc/ssh/sshd_config file.

Tip: Before editing the configuration file, you should make a copy of the original /etc/ssh/sshd_config file and protect it from writing so you will have the original settings as a reference and to reuse as necessary. You can do this with the following commands:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
sudo chmod a-w /etc/ssh/sshd_config.original

Since losing an SSH server might mean losing your way to reach a server, check the configuration after changing it and before restarting the server:

sudo sshd -t -f /etc/ssh/sshd_config

Example configuration directive

Let’s take a look at an example of a configuration directive change. To make your OpenSSH server display the contents of the /etc/issue.net file as a pre-login banner, you can add or modify this line in the /etc/ssh/sshd_config file:

Banner /etc/issue.net

After making changes to the /etc/ssh/sshd_config file, save the file. Then, restart the sshd server application to effect the changes using the following command:

sudo systemctl restart sshd.service

Warning: Many other configuration directives for sshd are available to change the server application’s behavior to fit your needs. Be advised, however, if your only method of access to a server is SSH, and you make a mistake when configuring sshd via the /etc/ssh/sshd_config file, you may find you are locked out of the server upon restarting it. Additionally, if an incorrect configuration directive is supplied, the sshd server may refuse to start, so be particularly careful when editing this file on a remote server.

SSH keys

SSH allows authentication between two hosts without the need of a password. SSH key authentication uses a private key and a public key.

To generate the keys, run the following command:

ssh-keygen -t rsa

This will generate the keys using the RSA Algorithm. At the time of this writing, the generated keys will have 3072 bits. You can modify the number of bits by using the -b option. For example, to generate keys with 4096 bits, you can use:

ssh-keygen -t rsa -b 4096

During the process you will be prompted for a password. Simply hit Enter when prompted to create the key.

By default, the public key is saved in the file ~/.ssh/id_rsa.pub, while ~/.ssh/id_rsa is the private key. Now copy the id_rsa.pub file to the remote host and append it to ~/.ssh/authorized_keys by running:

ssh-copy-id username@remotehost

Finally, double check the permissions on the authorized_keys file – only the authenticated user should have read and write permissions. If the permissions are not correct then change them by:

chmod 600 .ssh/authorized_keys

You should now be able to SSH to the host without being prompted for a password.

Import keys from public keyservers

These days many users have already SSH keys registered with services like Launchpad or GitHub. Those can be imported with:

ssh-import-id <username-on-remote-service>

The prefix lp: is implied and means fetching from Launchpad. The alternative gh: will make the tool fetch from GitHub instead.

Two factor authentication with U2F/FIDO

OpenSSH 8.2 has added support for U2F/FIDO hardware authentication devices. These devices are used to provide an extra layer of security on top of the existing key-based authentication, as the hardware token needs to be present to finish the authentication.

It’s very simple to use and setup. The only extra step is to generate a new keypair that can be used with the hardware device. For that, there are two key types that can be used: ecdsa-sk and ed25519-sk. The former has broader hardware support, while the latter might need a more recent device.

Once the keypair is generated, it can be used as you would normally use any other type of key in OpenSSH. The only requirement is that in order to use the private key, the U2F device has to be present on the host.

Example with U2F

For example, plug the U2F device in and generate a keypair to use with it:

$ ssh-keygen -t ecdsa-sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation. <-- touch device
Enter file in which to save the key (/home/ubuntu/.ssh/id_ecdsa_sk): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ubuntu/.ssh/id_ecdsa_sk
Your public key has been saved in /home/ubuntu/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:V9PQ1MqaU8FODXdHqDiH9Mxb8XK3o5aVYDQLVl9IFRo ubuntu@focal

Now transfer the public part to the server to ~/.ssh/authorized_keys and you are ready to go:

$ ssh -i .ssh/id_ecdsa_sk ubuntu@focal.server
Confirm user presence for key ECDSA-SK SHA256:V9PQ1MqaU8FODXdHqDiH9Mxb8XK3o5aVYDQLVl9IFRo <-- touch device
Welcome to Ubuntu Focal Fossa (GNU/Linux 5.4.0-21-generic x86_64)
(...)
ubuntu@focal.server:~$

FIDO2 resident keys

FIDO2 private keys consist of two parts: a key handle part, stored in the private key file on disk, and a per-device key, which is unique to each FIDO2 token and cannot be exported from the token hardware. These are combined by the hardware at authentication time to derive the real key, which is used to sign authentication challenges.

For tokens that are required to move between computers, it can be cumbersome to have to move the private key file first. To avoid this, tokens implementing the newer FIDO2 standard support resident keys, where it is possible to retrieve the key handle part of the key from the hardware.

Using resident keys increases the likelihood of an attacker being able to use a stolen token device. For this reason, tokens normally enforce PIN authentication before allowing the download of keys, and users should set a PIN on their tokens before creating any resident keys. This is done via the hardware token management software.

OpenSSH allows resident keys to be generated using the ssh-keygen flag -O resident at key generation time:

$ ssh-keygen -t ecdsa-sk -O resident -O application=ssh:mykeyname
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: 
Enter file in which to save the key (/home/ubuntu/.ssh/id_ecdsa_sk): mytoken
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in mytoken
(...)

This will produce a public/private key pair as usual, but it will be possible to retrieve the private key part (the key handle) from the token later. This is done by running:

$ ssh-keygen -K
Enter PIN for authenticator: 
You may need to touch your authenticator to authorize key download.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Saved ECDSA-SK key ssh:mytoken to id_ecdsa_sk_rk_mytoken

It will use the part after ssh: from the application parameter from before as part of the key filenames:

$ l id_ecdsa_sk_rk_mytoken*
-rw------- 1 ubuntu ubuntu 598 out  4 18:49 id_ecdsa_sk_rk_mytoken
-rw-r--r-- 1 ubuntu ubuntu 228 out  4 18:49 id_ecdsa_sk_rk_mytoken.pub

If you set a passphrase when extracting the keys from the hardware token, and later use these keys, you will be prompted for both the key passphrase and the hardware key PIN. You will also have to touch the token:

$ ssh -i ./id_ecdsa_sk_rk_mytoken ubuntu@focal.server
Enter passphrase for key './id_ecdsa_sk_rk_mytoken': 
Confirm user presence for key ECDSA-SK 
SHA256:t+l26IgTXeURY6e36wtrq7wVYJtDVZrO+iuobs1CvVQ
User presence confirmed
(...)

It is also possible to download and add resident keys directly to ssh-agent by running

$ ssh-add -K

In this case, no file is written and the public key can be printed by running ssh-add -L.

Note: If you used the -O verify-required option when generating the keys, or if that option is set on the SSH server via the /etc/ssh/sshd_config setting PubkeyAuthOptions verify-required, then using the agent won’t work (in Ubuntu 22.04 LTS).

Two factor authentication with TOTP/HOTP

For the best two factor authentication (2FA) security, we recommend using hardware authentication devices that support U2F/FIDO. See the previous section for details. However, if this is not possible or is impractical to implement in your case, TOTP/HOTP based 2FA is an improvement over no two factor at all. Smartphone apps to support this type of 2FA are common, such as Google Authenticator.

Background

The configuration presented here makes public key authentication the first factor, the TOTP/HOTP code the second factor, and makes password authentication unavailable. Apart from the usual setup steps required for public key authentication, all configuration and setup takes place on the server. No changes are required at the client end; the 2FA prompt appears in place of the password prompt.

The two supported methods are HMAC-based One Time Password (HOTP) and Time-based One Time Password (TOTP). Generally, TOTP is preferable if the 2FA device supports it.

HOTP is based on a sequence predictable only to those who share a secret. The user must take an action to cause the client to generate the next code in the sequence, and this response is sent to the server. The server also generates the next code, and if it matches the one supplied by the user, then the user has proven to the server that they share the secret. A downside of this approach is that if the user generates codes without the server following along, such as in the case of a typo, then the sequence generators can fall “out of sync”. Servers compensate by allowing a gap in the sequence and considering a few subsequent codes to also be valid; if this mechanism is used, then the server “skips ahead” to sync back up. But to remain secure, this can only go so far before the server must refuse. When HOTP falls out of sync like this, it must be reset using some out-of-band method, such as authenticating using a second backup key in order to reset the secret for the first one.

TOTP avoids this downside of HOTP by using the current timezone-independent date and time to determine the appropriate position in the sequence. However, this results in additional requirements and a different failure mode. Both devices must have the ability to tell the time, which is not practical for a USB 2FA token with no battery, for example. And both the server and client must agree on the correct time. If their clocks are skewed, then they will disagree on their current position in the sequence. Servers compensate for clock skew by allowing a few codes either side to also be valid. But like HOTP, they can only go so far before the server must refuse. One advantage of TOTP over HOTP is that correcting for this condition involves ensuring the clocks are correct at both ends; an out-of-band authentication to reset unfortunate users’ secrets is not required. When using a modern smartphone app, for example, the requirement to keep the clock correct isn’t usually a problem since this is typically done automatically at both ends by default.

Note: It is not recommended to configure U2F/FIDO at the same time as TOTP/HOTP. This combination has not been tested, and using the configuration presented here, TOTP/HOTP would become mandatory for everyone, whether or not they are also using U2F/FIDO.

Install required software

From a terminal prompt, install the google-authenticator PAM module:

sudo apt update
sudo apt install libpam-google-authenticator

Note: The libpam-google-authenticator package is in Ubuntu’s universe archive component, which receives best-effort community support only.

Configure users

Since public key authentication with TOTP/HOTP 2FA is about to be configured to be mandatory for all users, each user who wishes to continue using SSH must first set up public key authentication and then configure their 2FA keys by running the user setup tool. If this isn’t done first, users will not be able to do it later over SSH, since at that point they won’t have public key authentication and/or 2FA configured to authenticate with.

Configure users’ key-based authentication

To set up key-based authentication, see “SSH Keys” above. Once this is done, it can be tested independently of subsequent 2FA configuration. At this stage, user authentication should work with keys only, requiring the supply of the private key passphrase only if it was configured. If configured correctly, the user should not be prompted for their password.

Configure users’ TOTP/HOTP 2FA secrets

Each user needs to run the setup tool to configure 2FA. This will ask some questions, generate a key, and display a QR code for the user to import the secret into their smartphone app, such as the Google Authenticator app on Android. The tool creates the file ~/.google-authenticator, which contains a shared secret, emergency passcodes and per-user configuration.

As a user who needs 2FA configured, from a terminal prompt run the following command:

google-authenticator

Follow the prompts, scanning the QR code into your 2FA app as directed.

It’s important to plan for the eventuality that the 2FA device gets lost or damaged. Will this lock the user out of their account? In mitigation, it’s worthwhile for each user to consider doing one or more of the following:

• Use the 2FA device’s backup or cloud sync facility if it has one.
• Write down the backup codes printed by the setup tool.
• Take a photo of the QR code.
• (TOTP only) Scan the QR code on multiple 2FA devices. This only works for TOTP, since multiple HOTP 2FA devices will not be able to stay in sync.
• Ensure that the user has a different authentication path to be able to rerun the setup tool if required.

Of course, any of these backup steps also negate any benefit of 2FA should someone else get access to the backup, so the steps taken to protect any backup should be considered carefully.

Configure the SSH server

Once all users are configured, configure sshd itself by editing /etc/ssh/sshd_config. Depending on your installation, some of these settings may be configured already, but not necessarily with the values required for this configuration. Check for and adjust existing occurrences of these configuration directives, or add new ones, as required:

KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive

Note: On Ubuntu 20.04 “Focal Fossa” and earlier, use ChallengeResponseAuthentication yes instead of KbdInteractiveAUthentication yes.

Restart the ssh service to pick up configuration changes:

sudo systemctl try-reload-or-restart ssh

Edit /etc/pam.d/sshd and replace the line:

@include common-auth

with:

auth required pam_google_authenticator.so

Changes to PAM configuration have immediate effect, and no separate reloading command is required.

Log in using 2FA

Now when you log in using SSH, in addition to the normal public key authentication, you will be prompted for your TOTP or HOTP code:

$ ssh jammy.server
Enter passphrase for key 'id_rsa':
(ubuntu@jammy.server) Verification code:
Welcome to Ubuntu Jammy Jellyfish...
(...)
ubuntu@jammy.server:~$

Special cases

On Ubuntu, the following settings are default in /etc/ssh/sshd_config, but if you have overridden them, note that they are required for this configuration to work correctly and must be restored as follows:

UsePAM yes
PubkeyAuthentication yes

Remember to run sudo systemctl try-reload-or-restart ssh for any changes made to sshd configuration to take effect.

Further reading

• Ubuntu Wiki SSH page.
• OpenSSH Website
• OpenSSH 8.2 release notes
• Advanced OpenSSH Wiki Page
• Yubikey documentation for OpenSSH FIDO/FIDO2 usage
• Wikipedia on TOTP
• Wikipedia on HOTP

Setting Up Bootloader – moving all files to external drive

/dev/sda2: UUID="5d160756-e6bb-42fa-bdd6-9e1f53987456" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="4a41b4c4-02"







menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-29d512>
        recordfail
        load_video
        gfxmode $linux_gfx_mode
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_msdos
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 5d160756-e6bb-42fa-bdd6-9e1f53987456
        linux   /boot/vmlinuz-6.1.54-10001-gd517e36a604d root=UUID=5d160756-e6bb-42fa-bdd6-9e1f53987456 ro  root=UUID=5>
        initrd  /boot/initrd.img-6.1.54-10001-gd517e36a604d
}
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-5d160756-e6bb-42fa-bdd6-9e1f53987456' {
        menuentry 'Ubuntu, with Linux 6.1.54-10001-gd517e36a604d' --class ubuntu --class gnu-linux --class gnu --class >
                recordfail
                load_video
                gfxmode $linux_gfx_mode
                insmod gzio
                if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
                insmod part_msdos
                insmod btrfs
                search --no-floppy --fs-uuid --set=root 5d160756-e6bb-42fa-bdd6-9e1f53987456
                echo    'Loading Linux 6.1.54-10001-gd517e36a604d ...'
                linux   /boot/vmlinuz-6.1.54-10001-gd517e36a604d root=UUID=5d160756-e6bb-42fa-bdd6-9e1f53987456 ro  roo>
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-6.1.54-10001-gd517e36a604d
        }
        menuentry 'Ubuntu, with Linux 6.1.54-10001-gd517e36a604d (recovery mode)' --class ubuntu --class gnu-linux --cl>
                recordfail
                load_video
                insmod gzio
                if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
                insmod part_msdos
                insmod btrfs
                search --no-floppy --fs-uuid --set=root 5d160756-e6bb-42fa-bdd6-9e1f53987456
                echo    'Loading Linux 6.1.54-10001-gd517e36a604d ...'
                linux   /boot/vmlinuz-6.1.54-10001-gd517e36a604d root=UUID=5d160756-e6bb-42fa-bdd6-9e1f53987456 ro reco>
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-6.1.54-10001-gd517e36a604d
        }
}

The warning about hdmi-audio-codec Asoc: error at snd_soc_ida_hw-params typically indicates an issue with initializing the HDMI audio codec—essentially, the system is trying to configure HDMI for audio output, but it encounters an error. Since you mentioned there isn’t supposed to be any audio output on this setup, it’s safe to ignore this warning as it doesn’t impact functionality.

However, if you’d like to get rid of the warning or prevent the system from attempting to configure audio through HDMI, you can try the following:

Option 1: Disable HDMI Audio in Device Tree (for ARM SBCs)

Many ARM-based boards use a Device Tree to manage hardware configurations. You can modify or disable certain features directly from the Device Tree.

1. Locate the Device Tree File:

• The Device Tree is usually loaded from the boot partition and can be modified to disable HDMI audio.

• Look for a file named something like rk3328-roc.dtb or rk3328-*.dtb under /boot/ or /boot/dtb/.

2. Decompile the Device Tree (Optional):

• You can decompile the Device Tree Binary (DTB) to a source (DTS) file using dtc:

dtc -I dtb -O dts -o rk3328-roc.dts /boot/dtb/rk3328-roc.dtb

• Edit the DTS file to disable the HDMI audio node.

3. Recompile and Replace:

• Recompile the DTS back to DTB:

dtc -I dts -O dtb -o rk3328-roc.dtb rk3328-roc.dts

• Replace the existing DTB file with your modified version in /boot/.

Option 2: Blacklist the HDMI Audio Driver

If the HDMI audio driver is being loaded as a kernel module, you can blacklist it to prevent it from loading.

1. Identify the Driver:

• Run lsmod to see which kernel modules are loaded, and look for any HDMI or audio-related modules.

2. Blacklist the Module:

• Add the module name to the blacklist file:

sudo nano /etc/modprobe.d/blacklist.conf

• Add a line like:

blacklist snd_soc_hdmi_codec

• Replace snd_soc_hdmi_codec with the appropriate module name if it’s different.

3. Update Initramfs:

• If necessary, update the initramfs so that the blacklist change is applied at boot:

sudo update-initramfs -u

Option 3: Kernel Parameters

Another way to prevent the HDMI audio from being loaded is by modifying the kernel boot parameters.

1. Edit Grub or Bootloader Configuration:

• Edit /etc/default/grub and add the following to the GRUB_CMDLINE_LINUX_DEFAULT line:

snd_hda_intel.enable=0

• Update GRUB and reboot:

sudo update-grub

sudo reboot

Summary

• The HDMI audio warning indicates that the system is trying to configure audio output via HDMI but fails. Since you don’t need audio, it’s safe to ignore it.

• If you want to get rid of the warning:

• Disable HDMI Audio in the Device Tree.

• Blacklist the HDMI audio kernel module.

• Add a kernel parameter to prevent the audio driver from loading.

If the warning isn’t causing any issues with system performance, it’s perfectly fine to leave it alone, especially if audio isn’t needed.

boot$ ls
System.map-6.1.54-10001-gd517e36a604d  firmware                               vmlinuz-6.1.54-10001-gd517e36a604d
config-6.1.54-10001-gd517e36a604d      grub
efi                                    initrd.img-6.1.54-10001-gd517e36a604d

It looks like you’re listing the contents of the boot directory (/boot), which contains several important files related to booting your system. Let’s go over what these files are and what each does:

Understanding the Files in /boot Directory

1. System.map-6.1.54-10001-gd517e36a604d:

• System.map is a symbol table that maps kernel symbols to their memory addresses. It’s mostly used for debugging and system diagnostics.

• The numbers (6.1.54-10001-gd517e36a604d) represent the kernel version.

2. config-6.1.54-10001-gd517e36a604d:

• config contains the configuration options used to build the kernel. It can be useful if you want to know which features are enabled in your kernel.

3. efi:

• The efi directory contains files related to EFI/UEFI booting. UEFI is the newer replacement for the BIOS, and the files here are used for initializing hardware and handing off the boot process to the OS loader.

4. firmware:

• firmware may contain device firmware or configuration files for specific hardware components that need firmware to be loaded during the boot process.

5. grub:

• The grub directory contains GRUB bootloader configuration files. GRUB (GNU GRand Unified Bootloader) is the program that allows you to select the operating system or kernel version during boot.

• Key files in this directory could include grub.cfg, which specifies the boot menu options.

6. initrd.img-6.1.54-10001-gd517e36a604d:

• initrd.img (initial RAM disk) is a temporary root file system used by the kernel to load drivers and other modules that are needed early in the boot process, before the actual root file system is available.

• The numbers after initrd.img match the kernel version, indicating that it’s used for that specific kernel.

7. vmlinuz-6.1.54-10001-gd517e36a604d:

• vmlinuz is the compressed Linux kernel binary that gets loaded into memory and executed. This file represents the kernel image used during boot.

• The numbers after vmlinuz match the kernel version as well, ensuring that the correct kernel version is booted.

Handling HDMI-Audio Warnings in /boot Context

If you’re looking to address the HDMI audio codec warnings we talked about earlier, you may need to modify kernel boot parameters or update configuration files related to GRUB or the Device Tree. Since you have access to the /boot directory, here’s how you can proceed:

Modify Kernel Boot Parameters in GRUB

1. Edit the GRUB Configuration:

• If you are using GRUB as your bootloader, you can add parameters to disable HDMI audio.

2. Locate and Edit grub.cfg:

• If you find a grub.cfg file inside the grub directory, it’s likely used by GRUB to load the kernel.

• However, the standard practice is to update /etc/default/grub and run update-grub. This will generate the correct configuration in /boot/grub/grub.cfg.

Example to edit /etc/default/grub:

sudo nano /etc/default/grub

Add the parameter to GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash snd_hda_intel.enable=0"

Then update GRUB:

sudo update-grub

Disabling HDMI Audio Through Device Tree

• If HDMI audio is controlled through the Device Tree, you would need to modify the Device Tree Blob (.dtb) files that might be found in /boot/efi or elsewhere.

• You would need to decompile (dtc -I dtb -O dts), modify (disable the HDMI audio node), and recompile it (dtc -I dts -O dtb).

Summary

The /boot directory contains critical files for booting your system, including the kernel (vmlinuz), initial RAM disk (initrd.img), and GRUB configuration. To handle HDMI audio warnings, consider:

1. GRUB Configuration:

• Modify kernel boot parameters in /etc/default/grub and add parameters to disable HDMI audio, then run update-grub.

2. Device Tree Modification (Optional, Advanced):

• If HDMI is managed through the Device Tree, modify the corresponding .dtb files.

Let me know if you need further guidance on modifying any specific part of the boot process to handle the HDMI warning!

I feel like there was a warning about grub needing some manual config - but it flashed by - 

It sounds like during an update or installation process, GRUB generated a warning that required some manual intervention. These messages can flash by quickly, especially during package installations or kernel upgrades. Let’s walk through the steps to verify and fix any issues that may need manual configuration for GRUB:

Step 1: Verify GRUB Installation

The first step is to make sure that GRUB is correctly installed and configured. You can do this by attempting to reinstall GRUB or by updating the GRUB configuration.

Option 1: Reinstall GRUB

1. Identify the Boot Drive:

• You need to know which drive to install GRUB on, typically the main drive such as /dev/sda or /dev/mmcblk0.

• To list all drives:

lsblk

2. Reinstall GRUB:

• If your boot drive is /dev/sda, reinstall GRUB like this:

sudo grub-install /dev/sda

• Replace /dev/sda with the appropriate device name if necessary.

Option 2: Update GRUB Configuration

Updating the GRUB configuration will regenerate the boot menu and may help resolve any configuration issues.

1. Edit /etc/default/grub (Optional):

• Before updating GRUB, you can add or modify boot parameters as needed.

sudo nano /etc/default/grub

2. Update GRUB:

• Run the following command to regenerate the GRUB configuration:

sudo update-grub

• This command will recreate the /boot/grub/grub.cfg file, which contains the boot menu options.

Step 2: Check /boot/grub/grub.cfg for Errors

1. Review GRUB Configuration File:

• Look for any syntax errors or unusual configurations in the /boot/grub/grub.cfg file. You can open it with a text editor:

sudo nano /boot/grub/grub.cfg

• Be careful not to make unnecessary edits directly in this file unless you are sure about what needs to be changed, as this file is usually automatically generated by update-grub.

Step 3: Check for Kernel or GRUB Errors

1. Run dmesg to Check Logs:

• The kernel messages may contain information about GRUB if there was an error during the boot process:

dmesg | grep grub

2. Check /var/log/boot.log or /var/log/syslog:

• These logs may also contain information about the GRUB boot process.

sudo cat /var/log/boot.log

or

sudo cat /var/log/syslog | grep grub

Step 4: Manually Regenerate Initramfs (if Necessary)

Sometimes GRUB issues are linked to the initial RAM disk (initrd) not being regenerated properly during a kernel update.

1. Regenerate the Initramfs:

sudo update-initramfs -u

• This will create or update the initrd.img file for the current kernel.

Step 5: Verify GRUB Device Mapping

Ensure GRUB knows which devices are available by checking the device map:

1. List GRUB Devices:

sudo grub-mkdevicemap

• This command will ensure that GRUB has an updated list of available devices to properly identify the boot device.

Summary of Steps

1. Reinstall GRUB: To ensure that it’s correctly installed on your primary boot drive (sudo grub-install /dev/sda).

2. Update GRUB Configuration: Edit /etc/default/grub if necessary and run sudo update-grub to regenerate the GRUB menu.

3. Check for Errors: Review /boot/grub/grub.cfg, logs (/var/log/syslog, dmesg), and device mapping to identify any issues.

4. Regenerate Initramfs: Update initrd.img with sudo update-initramfs -u.

By going through these steps, you can ensure that any configuration issues with GRUB are resolved and that your system will boot smoothly. If you see any specific errors or have more details about the warning that flashed by, let me know, and I can help further!

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0 109.6M  1 loop /snap/lxd/24326
loop1         7:1    0  77.4M  1 loop /snap/lxd/29353
loop2         7:2    0  59.2M  1 loop /snap/core20/1977
loop3         7:3    0  46.4M  1 loop /snap/snapd/19459
loop4         7:4    0  33.7M  1 loop /snap/snapd/21761
mmcblk1     179:0    0  29.8G  0 disk
├─mmcblk1p1 179:1    0   256M  0 part /boot/efi
└─mmcblk1p2 179:2    0  29.5G  0 part /

From the output you’ve shared, it looks like your system has the following storage devices and partitions:

Understanding the Output

1. Loop Devices (loop0, loop1, loop2, etc.):

• loop0 – loop4 are loopback devices that are commonly used by snap packages. These represent mounted snaps for applications like lxd and core. They are read-only mounts created by the Snap system.

• These loop devices aren’t physical disks but are used to mount Snap package images in your system.

2. MMC Device (mmcblk1):

• mmcblk1 is a memory card (eMMC or SD card) with a size of 29.8 GB.

• It contains two partitions:

• mmcblk1p1 (256 MB, Type: Part): This partition is mounted at /boot/efi, which suggests that it’s used for the UEFI boot files.

• mmcblk1p2 (29.5 GB, Type: Part): This partition is mounted at the root filesystem (/), meaning it contains the main OS and all system files.

Next Steps: Installing or Updating GRUB

Based on this, it looks like your system’s root filesystem is located on the eMMC card (mmcblk1). You would typically need to ensure that GRUB is installed correctly on this device. Below, I’ll provide the steps for reinstalling GRUB and updating the configuration to make sure everything is working correctly.

Step 1: Reinstall GRUB

Since your boot drive is mmcblk1, you need to install GRUB on this drive:

sudo grub-install /dev/mmcblk1

This command will install GRUB on the eMMC card, which is your main boot device. It will configure GRUB to load the kernel and initial RAM disk from the correct partitions.

Step 2: Update GRUB Configuration

After reinstalling GRUB, update the GRUB configuration file:

1. Edit /etc/default/grub (Optional):

• You can modify kernel parameters if needed by editing this file:

sudo nano /etc/default/grub

• Example: You could add kernel parameters for HDMI audio or other configurations.

2. Update GRUB:

• Run the following command to regenerate the GRUB configuration file (/boot/grub/grub.cfg):

sudo update-grub

Step 3: Verify Boot Partition Setup

Since you have a separate EFI partition (mmcblk1p1), you need to ensure that GRUB has correctly placed the necessary files in this partition. When GRUB is installed, it should automatically place the required boot files in /boot/efi.

You can verify that the EFI directory has GRUB files:

ls /boot/efi/EFI

You should see a directory for GRUB, typically named ubuntu or something similar. This directory contains the bootloader files needed by UEFI.

Summary

• Reinstall GRUB on /dev/mmcblk1 to ensure it’s correctly installed on the boot device.

sudo grub-install /dev/mmcblk1

• Update GRUB Configuration to reflect any new kernel versions or parameters.

sudo update-grub

• Check /boot/efi to verify that GRUB files are correctly placed in the EFI partition.

These steps should help ensure that your system boots correctly, using the UEFI partition for the initial boot sequence. If you need to troubleshoot further or see specific error messages, let me know, and we can dive deeper!

adn here are the warnings I saw - 

ubuntu@ubuntu-22:/boot$ sudo grub-install /dev/mmcblk1
Installing for arm64-efi platform.
grub-install: warning: EFI variables cannot be set on this system.
grub-install: warning: You will have to complete the GRUB setup manually.
Installation finished. No error reported.
ubuntu@ubuntu-22:/boot$

Yes, it’s perfectly fine to have changed the type of partition from ‘Linux’ to ‘EFI (FAT-12/16/32)’, and using 1000 MB is more than sufficient for an EFI System Partition (ESP). This partition will store the bootloader files needed by the UEFI firmware to boot your system.

Review of What You Have Done So Far

• Partition 1 (/dev/sda1): You created a 1000 MB partition and changed its type to EFI. You then formatted it as FAT32 using mkfs.vfat -F 32 /dev/sda1.

• This partition will be your EFI System Partition to store the GRUB bootloader and other related files for booting.

Step-by-Step Check and Move Forward

Now you need to create the root partition and proceed with setting up the drive as the bootable device:

Step 1: Create a New Root Partition on /dev/sda

1. Open fdisk for /dev/sda:

sudo fdisk /dev/sda

2. Create a New Partition:

• Press n to create a new partition.

• Choose p for primary.

• Partition Number: This will be 2.

• First Sector: Press Enter to accept the default (immediately after the first partition).

• Last Sector: Press Enter to accept the default, which will use the rest of the available space for the root filesystem.

3. Write the Changes:

• Press w to write the changes and exit.

Step 2: Format the Root Partition

Format the newly created root partition (/dev/sda2) as ext4:

sudo mkfs.ext4 /dev/sda2

Step 3: Clone the File System

With both partitions set up, you can now clone the existing filesystem from the microSD card to the external drive.

1. Mount the Existing Root Partition on microSD (/dev/mmcblk1p2):

sudo mkdir -p /mnt/sdcard

sudo mount /dev/mmcblk1p2 /mnt/sdcard

2. Mount the New Root Partition on the External Drive (/dev/sda2):

sudo mkdir -p /mnt/external

sudo mount /dev/sda2 /mnt/external

3. Mount the New EFI Partition (/dev/sda1):

sudo mkdir -p /mnt/external/boot/efi

sudo mount /dev/sda1 /mnt/external/boot/efi

4. Use rsync to Copy the Filesystem:

sudo rsync -axHAWXS –numeric-ids –info=progress2 /mnt/sdcard/ /mnt/external/

This command will clone everything from the root filesystem of the SD card to the new external drive.

Step 4: Install GRUB on the External Drive

Now install GRUB on the external drive (/dev/sda):

sudo grub-install –target=arm64-efi –efi-directory=/mnt/external/boot/efi –boot-directory=/mnt/external/boot /dev/sda

This command installs GRUB for the UEFI platform, using the EFI partition you created and pointing to the boot directory on the new root partition.

Step 5: Update fstab for the New Root Partition

Update the /etc/fstab file on the new root partition so that the system knows where to mount its partitions when it boots.

1. Get the UUIDs for the New Partitions:

• EFI Partition (/dev/sda1):

sudo blkid /dev/sda1

• Root Partition (/dev/sda2):

sudo blkid /dev/sda2

2. Edit the fstab File on the New Root Partition:

sudo nano /mnt/external/etc/fstab

• Update the entries for /boot/efi and / (root) to use the correct UUIDs. The entries might look like:

UUID= / ext4 defaults 0 1

UUID= /boot/efi vfat defaults 0 1

• Replace and with the actual UUIDs you obtained using blkid.

Step 6: Reboot and Test Booting from External Drive

1. Unmount All Partitions:

• Unmount the SD card and the external drive:

sudo umount /mnt/sdcard

sudo umount /mnt/external/boot/efi

sudo umount /mnt/external

2. Reboot the System:

• Shut down your ROC-RK3328-CC, remove the microSD card, and leave the external USB drive connected.

• Power it on to see if it successfully boots from the USB drive.

Summary

• Partition Setup:

• Partition 1 (/dev/sda1): EFI System Partition, formatted as FAT32.

• Partition 2 (/dev/sda2): Root Partition, formatted as ext4.

• Clone Filesystem: Use rsync to clone the system from the microSD card.

• Install GRUB: Install GRUB to make the external drive bootable.

• Update fstab: Modify /etc/fstab on the new drive to point to the correct UUIDs.

• Reboot to test booting from the external USB drive.

These steps will help you set up the external drive as the new boot drive for your ROC-RK3328-CC. Let me know if you run into any issues or need further clarification!

ubuntu@ubuntu-22:/boot$ sudo mkfs.ext4 /dev/sda2
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 62258518 4k blocks and 15564800 inodes
Filesystem UUID: 5d160756-e6bb-42fa-bdd6-9e1f53987456
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks):

It looks like the root partition (/dev/sda2) is being successfully formatted as ext4. The mkfs.ext4 command is in the process of creating the filesystem, including allocating group tables, writing inode tables, and creating the journal.

This is a normal part of the formatting process, especially for larger drives like yours. It might take some time to complete, especially since it needs to set up various components of the filesystem to ensure it can manage data efficiently and reliably.

Next Steps After Formatting Completes

Once the formatting is complete, you can proceed with the following steps:

1. Mount the Partitions

• Mount the Existing Root Partition on the microSD card:

sudo mkdir -p /mnt/sdcard

sudo mount /dev/mmcblk1p2 /mnt/sdcard

• Mount the New Root Partition (/dev/sda2) on the USB drive:

sudo mkdir -p /mnt/external

sudo mount /dev/sda2 /mnt/external

• Mount the New EFI Partition (/dev/sda1) on the USB drive:

sudo mkdir -p /mnt/external/boot/efi

sudo mount /dev/sda1 /mnt/external/boot/efi

2. Clone the Filesystem

Use rsync to copy all files from the root filesystem of the microSD card to the new root partition:

sudo rsync -axHAWXS –numeric-ids –info=progress2 /mnt/sdcard/ /mnt/external/

This command ensures that all files, permissions, and symbolic links are copied accurately from the microSD card to the USB drive.

3. Install GRUB

After the filesystem is cloned, you need to install GRUB on the external USB drive:

sudo grub-install –target=arm64-efi –efi-directory=/mnt/external/boot/efi –boot-directory=/mnt/external/boot /dev/sda

This will install the bootloader to make your external USB drive bootable.

4. Update /etc/fstab

Edit the /etc/fstab file on the new root partition to make sure the system knows where to mount the necessary partitions during boot.

1. Get the UUIDs for the new partitions using blkid:

sudo blkid /dev/sda1

sudo blkid /dev/sda2

2. Edit the fstab file:

sudo nano /mnt/external/etc/fstab

3. Update Entries:

• Use the UUIDs obtained from blkid to update the entries for the root partition (/) and EFI partition (/boot/efi):

UUID= / ext4 defaults 0 1

UUID= /boot/efi vfat defaults 0 1

Replace and with the actual UUIDs.

5. Unmount and Reboot

• Unmount All Partitions:

sudo umount /mnt/sdcard

sudo umount /mnt/external/boot/efi

sudo umount /mnt/external

• Reboot the System:

• Shut down the ROC-RK3328-CC, remove the microSD card, and leave the USB drive connected.

• Power the board back on and it should attempt to boot from the USB drive.

Summary

• You’re almost ready! The formatting of the root partition is completing, and after that, you can mount, clone the filesystem, install GRUB, and update the fstab configuration.

• Once all of this is done, unmount everything and reboot without the microSD card to test booting from the external USB drive.

If you encounter any issues or need help at any point during these steps, feel free to ask!

Installing for arm64-efi platform.
grub-install: warning: EFI variables cannot be set on this system.
grub-install: warning: You will have to complete the GRUB setup manually.
Installation finished. No error reported.
ubuntu@ubuntu-22:/mnt/external$

ROC-RK3328-CC (Renegade) Overview Resources and Guides

StartBoard

roc-rk3328-cc

librecomputer

Nov '22

1. Get a good power supply > 5.0V < 5.5V

1. Get a good MicroSD card
2. If not, you’re going to waste a lot of time.

Boot

• General Troubleshooting 229
• Board Specific Troubleshooting 117

GPIO Header

• GPIO Control 184
• Pinout/Pinmux Map 189
• Python 3 Binding
• I2C 5
• SPI 8
• PWM 6
• UART 7

Board Hardware

• LEDs 12
• Temperature/Thermal 113
• IR

Peripheral Hardware Guides

• Realtek USB WiFi Dongles 105

• Libre Computer Boards Overview and Resources
• SPI implementation assistance

Libre Computer Board ROC-RK3328-CC (Renegade) Mini Computer with Gigabit Ethernet and USB 3.0 (4GB)

Case – eleUniverse ABS Case with Heatsink & Fan for Libre Computer Board AMl-S905X-CC/ALL-H3-CC/ROC-RK3328-CC (Black)

Power Supply – GenBasic USB Type C 5V 3A 15W UL Listed Power Supply with Power Switch Indicator and MicroUSB Adapter for Raspberry Pi 3/4 Libre Computer Board (2 Pack, US Red LED Switch)

Connection – GenBasic WiFi 5 Bluetooth BT4 USB Mini Wireless Network Dongle Adapter for Linux 6.2+

Possibilities

Creating NAS

Other possible fixes for NAS Load

The logs you’ve shared give a good insight into what’s happening during the boot process. It sounds like the delay is indeed related to device initialization and USB/Network detection. Let me break down what’s happening and suggest some potential approaches to address the long boot time.

Key Observations from Boot Logs:

1. 147 Seconds for Network and Cloud Init:

• The message you mentioned, “modules: final took 147 seconds” and “cloud-init took 147.54 seconds”, likely refers to how long it took to complete initializing network services and cloud-init. This means that a large part of the visible boot time is due to network-related setup and waiting for services.

2. USB and Network Device Detection:

• During the USB initialization, there are multiple USB disconnects and reconnects:

usb 2-1: USB disconnect, device number 6

usb 2-1.1: USB disconnect, device number 7

usb 2-1.2: USB disconnect, device number 8

usb 2-1.4: USB disconnect, device number 9

• These logs suggest the ROC board is repeatedly trying to initialize and detect USB devices, which might be causing the delays. It’s possible that the devices are not getting detected correctly on the first attempt, leading to repeated timeout and retry cycles.

3. USB Hub and Realtek Storage:

• The Realtek NVMe adapter and USB hubs are eventually detected and recognized, but it seems like the board is struggling to properly initialize everything, resulting in the long startup.

Potential Reasons for Slow Boot:

1. USB Power and Device Retry:

• The board might not be supplying enough power to the USB ports initially, causing multiple retries until the devices are properly recognized. This could be the reason why the network and USB storage devices are taking a long time to be detected.

2. Network and Cloud Init Delays:

• The cloud-init and network services might be taking a long time to finish, particularly if they’re waiting for DHCP or a network connection that isn’t ready. This can add significantly to the boot time.

3. Power Supply or Voltage Issue:

• Since you’re using a USB power meter, make sure that the power draw of all connected peripherals is within the limits of your power supply. Underpowered devices might be constantly resetting, leading to the long boot time.

Suggested Actions to Reduce Boot Time:

1. Disable Cloud Init if Not Needed:

• Cloud-init is a utility used to initialize cloud instances. If you are not using this board in a cloud environment, disabling cloud-init can save time during the boot process.

• You can disable cloud-init by creating a NoCloud configuration file or by masking the service:

sudo touch /etc/cloud/cloud-init.disabled

• Alternatively, disable it with systemd:

sudo systemctl mask cloud-init

• This should stop cloud-init from running during boot.

2. Check Network Configuration:

• The board might be spending a lot of time waiting for network initialization, especially if it’s waiting for a DHCP lease that isn’t available immediately.

• Consider setting a static IP address for the board to avoid waiting for DHCP. You can do this by editing the network configuration file (typically in /etc/netplan/ on Ubuntu).

• Example of a static IP configuration for Netplan:

network:

version: 2

ethernets:

eth0:

dhcp4: no

addresses: [192.168.1.14/24]

gateway4: 192.168.1.1

nameservers:

addresses: [8.8.8.8, 8.8.4.4]

• Apply the changes:

sudo netplan apply

3. USB Initialization Fixes:

• Disable USB Autosuspend:

• Sometimes autosuspend settings can cause USB devices to take longer to initialize. Try disabling autosuspend for USB:

• Add the following to /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="usbcore.autosuspend=-1"

• Then update GRUB:

sudo update-grub

• Plug Devices in One by One:

• During boot, try plugging in devices one by one. Start with the keyboard, then add the network adapter and storage device. This helps identify if a particular device is causing the delay.

4. Update U-Boot or Firmware:

• U-Boot or firmware updates can improve hardware initialization. Check for any available updates for the ROC board that may improve USB power management or device detection during boot.

5. Power Supply Check:

• Make sure your power adapter is 5V 3A as recommended. Also, check the quality of the USB power cable to ensure it can handle the required current without significant voltage drops.

• Your USB power meter shows that there is 0.002A current draw in the previous image, which indicates that there might not be enough power being delivered during initialization. Make sure the power supply is stable during the boot process.

6. Modify Boot Order in U-Boot:

• If you get into U-Boot, you can modify the boot order to ensure that it looks for the correct storage device first.

• Use the following command in U-Boot:

setenv boot_targets usb0 mmc1 mmc0

saveenv

• This command will prioritize USB devices over microSD cards during boot.

Summary of Actions

1. Disable cloud-init to reduce boot delays if it is not needed.

2. Set a static IP address to avoid delays from DHCP and speed up network initialization.

3. Disable USB autosuspend and check USB devices one by one to determine if any are causing the delay.

4. Check for firmware updates for the ROC board and ensure a stable power supply.

5. Modify U-Boot to adjust the boot order and prioritize the USB drive.

These steps should help you reduce the boot time significantly, and you should be able to further investigate if a particular USB device or service is contributing to the long delays. Let me know how these suggestions work for you, and if you need more specific guidance on any of these steps!

https://libre.computer/products/roc-rk3328-cc/

The ROC-RK3328-CC platform is built on the Rockchip RK3328 system-on-chip optimized for low cost, low power, and high performance IO. It features a high performance native USB 3.0 interface and Gigabit MAC. Libre Computer is one of the few Linux-based software and hardware solutions provider for this chip.

Product Features

• Form Factor Compatible with Raspberry Pi® 2/3 Model B/B+

• Quad 64-bit Low Power Cores

• Quad Core 3D GPU with OpenGL ES 2.0

• Rockchip Multimedia Processor

  • H.265
  • H.264
  • VP9

• HDMI 2.0 with 4K HDR support

• Up to 4GB DDR4

• USB 3.0

• Gigabit Ethernet MAC

Product Family

• ROC-RK3328-CM

Platform

• Rockchip RK3328 SoC

  • 4 ARM Cortex-A53 @ 1.4GHz

    • Cryptography Extensions

  • 2G + 2P ARM Mali-450 @ 500MHz

    • OpenGL ES 1.1 / 2.0
    • OpenVG 1.1

  • Multi-Media Processor

    • Decoders

      • VP9 P2 4K60
      • H.265 M10P@L5.1 4K60
      • H.264 H10P@L5.1 4K60
      • JPEG

    • Encoders

      • H.265 1080P30 or 2x H.265 720P30
      • H.264 1080P30 or 2x H.264 720P30

• 1GB/2GB/4GB 32-bit DDR4 SDRAM

Form Factor

• Libre Computer CC Standard

  • 85mm x 56mm x 20mm Exterior Dimension

  • 58mm x 49mm Mounting Center to Center

    • Same as Raspberry Pi® 3 Model B+

  • Similar Exterior IO as Raspberry Pi® 3 Model B+

    • Less USB Type-A Port from Rear Top Right Corner

Standard IO

• USB 2.0 Type-A
• USB 2.0 Type-A Dual-Role-Data Port
• USB 3.0 Type A
• Gigabit Ethernet
• 3.5mm TRRS CVBS/AV Jack
• HDMI 2.0 with 4K HDR Support
• Multi-Protocol IR Receiver with System Wake Support
• MicroUSB Power In
• MicroSD Card Slot with UHS SDR104 support
• eMMC 5.x Interface for Libre Computer Modules
• USB ROM Boot Button

Pin Headers

• 40 Pin Low Speed Header (I2S/PWM/I2C/2xUART/SPI/SPDIF) Header
• 3-Pin ADC (2xSARADC) Header
• 3-Pin PMIC Power Control Header

Power Consumption

• 5W Full Load
• 4W Typical Load
• < 1.5W Idle
• < 0.1 Wake Ready

Software Support

• Upstream Linux
• Upstream u-boot

Lifecycle

• 10 Years Hardware
• 15 Years Software

Source Code

• u-boot Upstream
• Linux Upstream
• Buildroot
• LibreELEC
• Armbian
• Android

Help

• Libre Computer Hub
• Headers Reference
• Performance Data

Distros

Debian

Fedora

Ubuntu

OpenSUSE

Raspbian

Batocera

LibreELEC

Android

Lakka

Armbian

Other Downloads

Links coming soon!