View Chinese description | 查看中文说明
GitHub Actions is a service launched by Microsoft that provides a virtual server environment with excellent performance configurations. Based on this, you can build, test, package, and deploy projects. For public repositories, it can be used free of charge with no time limit, and each build can last up to 6 hours. This is sufficient for compiling Armbian (usually we can complete a compilation within about 3 hours). Sharing is just for the purpose of exchanging experiences, please understand any shortcomings, do not initiate any harmful attacks on the network, and do not misuse GitHub Actions.
- Armbian Build and Usage Guide
- Table of Contents
- 1. Register your own Github account
- 2. Set up private variable GITHUB_TOKEN
- 3. Fork the repository and set up GH_TOKEN
- 4. Customization instructions for personalized Armbian system files
- 5. Compile the system
- 6. Saving the System
- 7. Downloading the System
- 8. Installing Armbian to EMMC
- 8.1 Installation Method for Amlogic Series
- 8.2 Installation Method for Rockchip Series
- 8.3 Allwinner Series Installation Method
- 9. Compiling Armbian Kernel
- 10. Updating Armbian Kernel
- 11. Installing Common Software
- 12. Frequently Asked Questions
- 12.1 dtb and u-boot Correspondence Table for Each Box
- 12.2 Instructions for LED Screen Display Control
- 12.3 How to Restore the Original Android TV System
- 12.4 Setting the box to boot from USB/TF/SD
- 12.5 Disable Infrared Receiver
- 12.6 Boot file selection
- 12.7 Network Configuration
- 12.7.1 Network Configuration Using Interfaces
- 12.7.2 Network Management Using NetworkManager
- 12.7.3 How to Enable Wireless
- 12.7.4 How to Enable Bluetooth
- 12.8 How to Add Startup Tasks
- 12.9 How to Update Service Scripts in the System
- 12.10 How to Get Android System Partition Information on eMMC
- 12.11 How to build the u-boot file
- 12.12 Error in Memory Size Recognition
- 12.13 How to Decompile dtb Files
- 12.14 How to Modify cmdline Settings
- 12.15 How to Add New Supported Devices
- 12.16 How to Resolve the Issue of I/O Errors While Writing to eMMC
- 12.17 How to Solve the Issue of No Sound in the Bullseye Version
- 12.18 How to build the boot.scr file
- 12.19 How to Enable Remote Desktop and Modify the Default Port
Register your own account in order to continue with the customized operation of the system. Click the Sign up
button in the upper right corner of the github.com website and follow the instructions to register your account.
Set up Github private variable GITHUB_TOKEN
. After the system is compiled, we need to upload the system to Releases, we set this variable according to Github's official requirements, the method is as follows:
Personal center: Settings > Developer settings > Personal access tokens > Generate new token ( Name: GITHUB_TOKEN, Select: public_repo ). Other options can be selected as needed. Submit to save, copy the encrypted KEY value generated by the system, and save it to your computer's notepad. This value will be used in the next step. The illustration is as follows:
Now you can Fork the repository. Open the repository https://github.com/ophub/amlogic-s9xxx-armbian, click the Fork button in the upper right, copy a copy of the repository code to your account, wait a few seconds, after the Fork is complete, visit your own amlogic-s9xxx-armbian in your own repository. In the upper right corner, Settings
> Secrets
> Actions
> New repostiory secret
( Name: GH_TOKEN
, Value: Fill in the value of GITHUB_TOKEN just now
), save. And select Read and write permissions
in Actions
> General
> Workflow permissions
on the left navigation bar and save. The illustration is as follows:
The system compilation process is controlled in the .github/workflows/build-armbian.yml file. There are other .yml files in the workflows directory that implement different functions. The system is compiled in real time using Armbian's current official code, and related parameters can be referred to the official documentation.
- name: Compile Armbian [ ${{ inputs.set_release }} ]
id: compile
if: ${{ steps.down.outputs.status }} == 'success' && !cancelled()
run: |
# Compile method and parameter description: https://docs.armbian.com/Developer-Guide_Build-Options
cd build/
./compile.sh RELEASE=${{ inputs.set_release }} BOARD=odroidn2 BRANCH=current BUILD_MINIMAL=no \
BUILD_ONLY=default HOST=armbian BUILD_DESKTOP=no EXPERT=yes KERNEL_CONFIGURE=no \
COMPRESS_OUTPUTIMAGE="sha" SHARE_LOG=yes
echo "status=success" >> ${GITHUB_OUTPUT}
There are many ways to compile the system. You can set up timed compilation, manual compilation, or set some specific events to trigger the compilation. Let's start with simple operations.
In your repository's navigation bar, click the Actions button, then sequentially click on Build armbian > Run workflow > Run workflow to start the compilation. Wait for approximately 3 hours. The compilation is completed once all processes have ended. The illustration is as follows:
In the .github/workflows/build-armbian.yml file, use Cron to set scheduled compilation. The five different positions respectively represent minutes (0 - 59) / hours (0 - 23) / date (1 - 31) / month (1 - 12) / day of the week (0 - 6)(Sunday - Saturday). Set the time by modifying the value at different positions. The system uses UTC standard time by default, please convert according to the time zone of your country.
schedule:
- cron: '0 17 * * *'
The default system configuration information is recorded in the model_database.conf file, in which the BOARD
name must be unique.
For those with BUILD
value as yes
, they are part of the default packaged systems for the box, these boxes can be used directly. Those with the default value as no
are not packaged. To use the unpackaged boxes, you need to download the same FAMILY
packaged system (recommend downloading 5.15/5.4
kernel system), after writing to USB
, you can open USB's boot partition
on the computer, modify FDT's dtb name
in /boot/uEnv.txt
file, to adapt to other boxes in the list.
When compiling locally, specify with the -b
parameter. When compiling in Actions on github.com, specify with the armbian_board
parameter. Using -b all
means to package all devices where BUILD
is yes
. When packaging with a specified BOARD
parameter, it can be packaged whether BUILD
is yes
or no
. For example: -b r68s_s905x3-tx3_s905l3a-cm311
.
The system save setting is also controlled in the .github/workflows/build-armbian.yml file. We upload the compiled system to the Releases provided by the official GitHub via script automatically.
- name: Upload Armbian image to Release
uses: ncipollo/release-action@main
if: ${{ env.PACKAGED_STATUS }} == 'success' && !cancelled()
with:
tag: Armbian_${{ env.ARMBIAN_RELEASE }}_${{ env.PACKAGED_OUTPUTDATE }}
artifacts: ${{ env.PACKAGED_OUTPUTPATH }}/*
allowUpdates: true
token: ${{ secrets.GH_TOKEN }}
body: |
These are the Armbian OS image
* OS information
Default username: root
Default password: 1234
Install command: armbian-install
Update command: armbian-update
Enter the Release section in the lower right corner of the repository homepage, select the system that corresponds to your box model. The illustration is as follows:
Amlogic, Rockchip, and Allwinner have different installation methods. Different devices have different storage, some use an external microSD card, some have eMMC, some support the use of various storage media such as NVMe. According to the different devices, their installation methods are introduced separately. First, download the Armbian system for your device from Releases, and decompress it into .img format for standby. Depending on your device, use different installation methods in the following summary.
After the installation is completed, connect the Armbian device to the router
, wait for the device to boot for 2 minutes
, and then check the IP
of the device named Armbian in the router for management settings using SSH
tool. The default username is root
, the default password is 1234
, and the default port is 22
.
Log in to the Armbian system (default user: root, default password: 1234) → Enter the command:
armbian-install
Optional Parameter | Default Value | Options | Description |
---|---|---|---|
-m | no | yes/no | Use Mainline u-boot |
-a | yes | yes/no | Use ampart partition table adjustment tool |
-l | no | yes/no | List. Display the entire device list |
Example: armbian-install -m yes -a no
The installation method for each device is different, introduced separately as follows.
Radxa-Rock5B has multiple storage mediums such as microSD/eMMC/NVMe to choose from, and the corresponding installation methods are also different. Download rk3588_spl_loader_v1.08.111.bin and spi_image.img files for later use. Download RKDevTool tool and driver for later use. Download Rufus or balenaEtcher disc writing tools for later use.
Use Rufus or balenaEtcher and other tools to write the Armbian system image into microSD, then insert the microSD with the system written into the device for use.
- Install using a microSD card: Write the Armbian system image into a microSD card, insert the microSD card into the device and start, upload the
armbian.img
image file to the microSD card, use thedd
command to write the Armbian image into NVMe, the command is as follows:
dd if=armbian.img of=/dev/mmcblk1 bs=1M status=progress
- Install using a USB to eMMC card reader: Connect the eMMC module to the computer, use Rufus or balenaEtcher and other tools to write the Armbian system image into eMMC, then insert the eMMC with the system written into the device for use.
- Install using the Maskrom mode: Turn off the power of the development board. Hold down the gold button. Insert the USB-A to Type-C cable into the ROCK 5B Type-C port, and the other end into the PC. Release the gold button. Check that the USB device prompts to find a MASKROM device. Right-click in the blank area of the list, and then choose to load the
rock-5b-emmc.cfg
configuration file (the configuration file and RKDevTool are in the same directory). Setrk3588_spl_loader_v1.08.111.bin
andArmbian.img
as shown below, and choose to write.
The ROCK-5B has an SPI flash memory on its motherboard. Installing the bootloader on this SPI flash memory can support other boot media (such as SATA, USB3, or NVMe) that are not directly supported by the SoC maskrom mode. To use NVMe, you must first write the SPI file. The method is as follows:
Power off the development board. Remove bootable devices, such as MicroSD cards, eMMC modules, etc. Press and hold the golden button (or silver button on some revisions of the development board). Insert the USB-A to C cable into the C-type port of ROCK-5B, and the other end into your PC. Release the golden button. Check for a MASKROM device in the USB devices. Right-click in the list box to load the configuration, then select the configuration file in the resource management folder (the configuration file and RKDevTool are in the same directory), select rk3588_spl_loader_v1.08.111.bin
and spi_image.img
files according to the figure below, and click write:
- Installation using a card reader: Insert the M.2 NVMe SSD into the M.2 NVMe SSD to USB3.0 card reader to connect to the host. Use tools such as Rufus or balenaEtcher to write the Armbian system image to NVMe, then plug the NVMe with the written system into the device to use.
- Installation using a microSD card: Write the Armbian system image to a microSD card, insert the microSD card into the device and boot, upload the
armbian.img
image file to the microSD card, use thedd
command to write the Armbian image into NVMe, the command is as follows:
dd if=armbian.img of=/dev/nvme0n1 bs=1M status=progress
Use tools such as Rufus or balenaEtcher to write the Armbian system image to microSD, then plug the microSD with the written system into the device to use.
- Download the RKDevTool tool and driver, unzip and install the DriverAssistant driver program, and open the RKDevTool tool for standby.
- In the shutdown state of R68s, insert the USB male-to-male cable first, then press and hold the Recovery key and plug in the 12V power supply, release the Recovery key after two seconds, the flashing tool will
discover a LOADER device
. - Right-click in the blank space of the RKDevTool tool operation interface to add an item.
- The address is
0x00000000
, the name isarmbian
, and the path is to select thearmbian.img
system file. - Select the added armbian line,
deselect other lines
, and clickexecute
to write. - Supplement: If other systems have been written into eMMC, please erase them in advanced features first, and then write the Armbian system. If it cannot be erased, write the
MiniLoaderAll.bin
bootloader file again first, then enterMASKROM
to write the Armbian system. MiniLoaderAll.bin boot file settings: address0xCCCCCCCC
, nameLoader
, path selects theMiniLoaderAll.bin
file in the Image directory of the RKDevTool flashing tool.
The method is reproduced from milton's tutorial. Flashing requires entering the Maskrom mode. First, disconnect all connections, short the CLK and GND (using TTL's GND, or the GND next to the small button is fine) two touch points, and then connect the USB to the PC, and you will detect the MASKROM device. Short point position is as follows:
Open the RKDevTool flashing tool, right-click to add an item.
- Address
0xCCCCCCCC
, nameBoot
, path selectrk3328_loader_v1.14.249.bin
. - Address
0x00000000
, namesystem
, path select theArmbian.img
system to be flashed. - Check the "Force Write by Address" option, click "Execute," and wait for the progress to complete on the right-hand download panel.
The method is reproduced from cc747's tutorial. Flashing requires entering the Maskrom mode. Make Chainedbox-L1-Pro in a power-off state, unplug all cables. With a USB male-to-male cable, one end is inserted into the USB2.0 interface of Chainedbox-L1-Pro, and the other end is inserted into the computer. Insert a paperclip into the Reset hole and press and hold it. Insert the power cord. Wait a few seconds until the discovered a LOADER device
appears at the bottom of the RKDevTool box before releasing the paperclip. Switch RKDevTool to Advanced Features
and click the Enter Maskrom
button, prompting Found a MASKROM device
. Right-click to add an item.
- Address
0xCCCCCCCC
, nameBoot
, path selectrk3328_loader_v1.14.249.bin
. - Address
0x00000000
, namesystem
, path select theArmbian.img
system to be flashed. - Check the "Force Write by Address" option, click "Execute," and wait for the progress to complete on the right-hand download panel.
Log in to the Armbian system (default user: root, default password: 1234) → Enter the command:
armbian-install
Kernel compilation is supported in Ubuntu20.04/22.04, Debian11 or Armbian systems. Both local compilation and GitHub Actions cloud compilation are supported. For specific methods, please refer to the Kernel Compilation Instructions.
When there is a common kernel patch directory (common-kernel-patches
) in the kernel patch directory tools/patch, or when there is a directory named the same as the kernel source repository
(for example, linux-5.15.y), you can use -p true
to automatically apply the kernel patch. The naming convention for the patch directory is as follows:
~/amlogic-s9xxx-armbian
└── compile-kernel
└── tools
└── patch
├── common-kernel-patches # Fixed directory name: stores common kernel patches for all versions
├── linux-5.15.y # Named after the kernel source library: stores dedicated patches
├── linux-6.1.y
├── linux-5.10.y-rk35xx
└── more kernel directory...
- When compiling the kernel locally, you can manually create the corresponding directory and add the corresponding custom kernel patches.
- When cloud compiling with GitHub Actions, you can use the
kernel_patch
parameter to specify the directory of the kernel patch in your repository, such as the usage of compile-beta-kernel.yml in the kernel repository:
- name: Compile the kernel
uses: ophub/amlogic-s9xxx-armbian@main
with:
build_target: kernel
kernel_version: 5.15.1_6.1.1
kernel_auto: true
kernel_patch: kernel-patch/beta
auto_patch: true
When using the kernel_patch
parameter to specify a custom kernel patch, please name the patch directory according to the above convention.
- Obtained from repositories such as Armbian and OpenWrt: for example, armbian/patch/kernel and openwrt/rockchip/patches-6.1, lede/rockchip/patches-5.15 etc., patches from these mainline kernel using repositories can generally be used directly.
- Obtained from commits in github.com repositories: Adding a
.patch
suffix to the correspondingcommit
address can generate the corresponding patch.
Before adding a custom kernel patch, it needs to be compared with the upstream kernel source repository unifreq/linux-k.x.y to confirm whether this patch has been added to avoid conflicts. Kernel patches that pass the test are recommended to be submitted to the series of kernel repositories maintained by unifreq. Each small step for a person is a big step for the world. Your contribution will make our use of Armbian and OpenWrt systems in the box more stable and interesting.
Log in to the Armbian system → Enter the command:
# Run as root user (sudo -i)
# If no parameter is specified, it will be updated to the latest version.
armbian-update
Optional Parameters | Default Value | Options | Description |
---|---|---|---|
-r | ophub/kernel | <owner>/<repo> |
Set the repository to download the kernel from github.com |
-u | Automatic | stable/flippy/dev/rk3588/rk35xx/h6 | Set the suffix of the used kernel's tags |
-k | Latest Version | Kernel Version | Set the Kernel Version |
-b | yes | yes/no | Automatically backup the kernel currently in use when updating the kernel |
-m | no | yes/no | Use the mainline u-boot |
-s | None | None/DiskName | [SOS] Restore the system kernel in eMMC/NVMe/sdX and other disks |
-h | None | None | View the usage help |
Example: armbian-update -k 5.15.50 -u dev
When specifying the kernel version number through the -k
parameter, you can accurately specify the specific version number, such as: armbian-update -k 5.15.50
, or you can specify the kernel series vaguely, such as: armbian-update -k 5.15
, when vaguely specifying, it will automatically use the latest version of the specified series.
When updating the kernel, the currently used system kernel will be automatically backed up, stored in the /ddbr/backup
directory, retaining the three most recently used kernel versions. If the newly installed kernel is unstable, you can restore to the backed-up kernel at any time:
# Enter the backup kernel directory, such as 6.6.12
cd /ddbr/backup/6.6.12
# Execute the kernel update command, which will automatically install the kernel in the current directory
armbian-update
[SOS]: In case of incomplete updates or other issues preventing the system from booting from eMMC/NVMe/sdX due to special reasons, you can boot an Armbian system with any kernel version from another disk such as USB. Then, run the command armbian-update -s
to update the kernel from the USB to eMMC/NVMe/sdX, achieving the purpose of rescue. If no disk parameter is specified, the kernel will be restored from the USB device to eMMC/NVMe/sdX by default. If there are multiple disks, you can accurately specify the disk name that needs to be restored. Examples are as follows:
# Restore the kernel in eMMC
armbian-update -s mmcblk1
# Restore the kernel in NVMe
armbian-update -s nvme0n1
# Restore the kernel in a removable storage device
armbian-update -s sda
# Disk names can be abbreviated as mmcblk1/nvme0n1/sda, etc., or use the complete name such as /dev/sda
armbian-update -s /dev/sda
# When the device has only one built-in storage (eMMC/NVMe/sdX), the disk name parameter can be omitted
armbian-update -s
If your network access to github.com is poor and you can't update online, you can manually download the kernel, upload it to any directory of the Armbian system, and enter the kernel directory to execute armbian-update
for local installation. If there's a complete set of kernel files in the current directory, it will use the kernel from the current directory for the update (the four kernel files needed for the update are header-xxx.tar.gz
, boot-xxx.tar.gz
, dtb-xxx.tar.gz
, modules-xxx.tar.gz
. Other kernel files are not necessary and their presence does not affect the update. The system can accurately identify needed kernel files). You can freely update among the optional kernels supported by the device, such as updating from kernel 6.6.12 to kernel 5.15.50.
Custom options set by -r
/-u
/-b
parameters can be permanently written into the relevant parameters in the individual configuration file /etc/ophub-release
, to avoid entering it each time. The corresponding settings are:
# Assign values to custom parameters
-r : KERNEL_REPO='ophub/kernel'
-u : KERNEL_TAGS='stable'
-b : KERNEL_BACKUP='yes'
Log in to the Armbian system → Enter the command:
armbian-software
Using the armbian-software -u
command, you can update the local software center list. Based on user feedback in Issue, we gradually integrate commonly used software to implement one-click installation/update/uninstallation and other quick operations. This includes docker images
, desktop software
, application services
, etc. See more instructions.
Here's a compilation of some common issues you may encounter while using Armbian.
The supported TV box list is located in the /etc/model_database.conf configuration file in the Armbian
system.
Please refer to the instructions.
The Android TV system on the device is usually backed up and restored using armbian-ddbr
.
In addition, the Android system can also be flashed into eMMC using the method of flashing via a cable. The download image of the Android system can be found in Tools.
We recommend that before you install the Armbian system on a brand new box, you first backup the original Android TV system that came with the box. This is in case you need to restore the system later. Boot the Armbian system from TF/SD/USB
, input the armbian-ddbr
command, and then enter b
when prompted to back up the system. The backup file is stored in /ddbr/BACKUP-arm-64-emmc.img.gz
, please download and save it. To restore the Android TV system, upload the backup file to the same path on the TF/SD/USB
device, enter the armbian-ddbr
command, and then enter r
when prompted to restore the system.
-
Generally, if you can boot from USB by reinserting the power supply, you can just reinstall. Try it multiple times if necessary.
-
If the screen is black after connecting to a monitor and you can't boot from USB, you'll need to short-circuit initialize the box. First, restore the box to the original Android system, and then reinstall the Armbian system. Download the amlogic_usb_burning_tool recovery tool and install it. Prepare a USB double male data cable and a paperclip.
-
Taking x96max+ as an example, confirm the location of the short-circuit point on the box's motherboard, and download the box's Android TV system package. Android TV systems and corresponding short-circuit point diagrams for other common devices can also be downloaded and viewed here.
Operating method:
1. Open USB Burning Tool:
[ File → Import image ]: X96Max_Plus2_20191213-1457_ATV9_davietPDA_v1.5.img
[ Select ]:Erase Flash
[ Select ]:Erase bootloader
Click on the [ Start ] button
2. Use the [ paperclip ] to short-circuit the [ two short-circuit points ] on the box's motherboard,
and at the same time use the [ USB double male data cable ] to connect the [ box ] with the [ computer ].
3. When you see the [ progress bar starts moving ], remove the paperclip, no longer short-circuit.
4. When you see [ progress bar at 100% ], the flashing is complete, the box has been restored to the Android TV system.
Click on the [ Stop ] button, unplug the [ USB double male data cable ] between the [ box ] and [ computer ].
5. If any of the above steps fail, try again until successful.
If the progress bar does not move, you can try plugging in the power supply. Normally, you don't need power support for flashing, only the power supply from the USB double male can meet the requirements.
Once you've finished restoring factory settings, the box has been restored to the Android TV system, and the other steps to install the Armbian system are the same as when you first installed the system, just repeat them.
Based on the situation of your own device, there are two methods to use: initial installation and reinstallation of the Armbian system.
- Insert the USB/TF/SD with the installed system into the box.
- Enable developer mode: Settings → About device → Version number (e.g., X96max plus...), rapidly click the left mouse button 5 times on the version number, until the system shows the prompt
You are now a developer
. - Enable USB debugging: System → Advanced options → Developer options (set
USB debugging
to enabled). EnableADB
debugging. - Install ADB tool: Download adb and extract it, copy the three files
adb.exe
,AdbWinApi.dll
,AdbWinUsbApi.dll
to thesystem32
andsyswow64
folders underc://windows/
, then open thecmd
command panel, use theadb --version
command, if it shows, it means it can be used. - Enter
cmd
command mode. Enter theadb connect 192.168.1.137
command (modify the IP according to your box, you can check it in the router device that the box is connected to), if the connection is successful, it will displayconnected to 192.168.1.137:5555
- Enter the
adb shell reboot update
command, the box will reboot and boot from your inserted USB/TF/SD, you can enter the system by accessing the system's IP address from the browser, or via SSH.
- In normal situations, you can directly insert the USB flash drive with Armbian installed and boot from it. USB booting takes priority over eMMC.
- In some cases, the device may not boot from the USB flash drive. In such cases, you can rename the
boot.scr
file in the/boot
directory of the Armbian system on the eMMC. For example, you can rename it toboot.scr.bak
. After that, you can insert the USB flash drive and boot from it. This way, you will be able to boot from the USB flash drive.
By default, support for the infrared receiver is enabled, but if you are using your TV box as a server, you might want to disable the IR kernel module to prevent it from mistakenly turning off your box. To completely disable IR, add the following line:
blacklist meson_ir
to /etc/modprobe.d/blacklist.conf
and restart.
-
Currently known devices, only
T95(s905x)
/T95Z-Plus(s912)
/BesTV-R3300L(s905l-b)
and a few other devices need to use the/bootfs/extlinux/extlinux.conf
file, which has been added by default in the system. If other devices need it, you can write the system into USB, double-click to open theboot
partition, and delete the.bak
in the system's built-in/boot/extlinux/extlinux.conf.bak
file name to use. When writing to eMMC,armbian-install
will automatically check. If theextlinux.conf
file exists, it will be created automatically. -
Other devices only need
/boot/uEnv.txt
to boot, do not modify theextlinux.conf.bak
file.
The default content of the network configuration file /etc/network/interfaces
is as follows:
source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback
source /etc/network/interfaces.d/*
auto eth0
iface eth0 inet dhcp
Modify the IP, gateway, and DNS according to your network condition.
source /etc/network/interfaces.d/*
auto eth0
allow-hotplug eth0
iface eth0 inet static
hwaddress ether 12:34:56:78:9A:DA
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1
Modify the MAC address according to your needs.
source /etc/network/interfaces.d/*
allow-hotplug eth0
no-auto-down eth0
auto eth0
iface eth0 inet manual
auto macvlan
iface macvlan inet dhcp
pre-up ip link add macvlan link eth0 type macvlan mode bridge
post-down ip link del macvlan link eth0 type macvlan mode bridge
auto lo
iface lo inet loopback
Preparation work before creating or modifying a network connection.
Check which network interfaces are available for establishing network connections.
nmcli device | grep -E "^[e].*|^[w].*|^[D].*|^[T].*" | awk '{printf "%-19s%-19s\n",$1,$2}'
The DEVICE
column displays the network interface name, and the TYPE
column displays the network interface type.
Where eth0
= the name of the first Ethernet card, eth1
= the name of the second Ethernet card, and so on. The same goes for wireless cards.
DEVICE TYPE
eth0 ethernet
eth1 ethernet
eth2 ethernet
eth3 ethernet
wlan0 wifi
wlan1 wifi
Check existing network connections on the device, including used and unused connections. When creating a new network connection, it is recommended not to use existing connection names.
nmcli connection show | grep -E ".*|^[N].*" | awk '{printf "%-19s%-19s\n", $1,$3}'
The NAME
column displays the name of the existing network connection, and the TYPE
column displays the network interface type.
Where ethernet
= Ethernet card, wifi
= wireless card, bridge
= bridge
NAME TYPE
cnc ethernet
lan ethernet
lte ethernet
tel ethernet
docker0 bridge
titanium wifi
cpe wifi
Create a new network connection on network interface eth0
and make it effective immediately (Dynamic IP Address
- IPv4 / IPv6
).
# Set ENV
MYCON=ether1 # New network connection name
MYETH=eth0 # Network interface name = eth0 / eth1 / eht2 / eth3
IPV6AGM=stable-privacy # IPv6 address status mode = stable-privacy / eui64
# Add ETH
nmcli connection add \
con-name $MYCON \
type ethernet \
ifname $MYETH \
autoconnect yes \
ipv6.addr-gen-mode $IPV6AGM
nmcli connection up $MYCON
ip -c -br address
Create a new network connection on network interface eth0
and make it effective immediately (Static IP Address
- IPv4
).
# Set ENV
MYCON=ether1 # Network connection name
MYETH=eth0 # Network interface name = eth0 / eth1 / eht2 / eth3
IP=192.168.67.167/24 # HOST IP address, where 24 is the subnet mask corresponding to 255.255.255.0
GW=192.168.67.1 # Gateway
DNS=119.29.29.29,223.5.5.5 # DNS server address
# Chg CON
nmcli connection add \
con-name $MYCON \
type ethernet \
ifname $MYETH \
autoconnect yes \
ipv4.method manual \
ipv4.addresses $IP \
ipv4.gateway $GW \
ipv4.dns $DNS
nmcli connection up $MYCON
ip -c -br address
Create a network connection on the wlan0
network interface and take effect immediately (Dynamic IP address
- IPv4 / IPv6
).
# Set ENV
MYCON=ssid # Name of the new network connection, it is recommended to use WiFi SSID to specify the connection name
MYSSID=ssid # WiFi SSID, case sensitive
MYPSWD=passwd # WiFi password
MYWSKM=wpa-psk # Security selection WPA-WPA2 = wpa-psk or WPA3 = sae (see which encryption method is in the wireless router or AP)
MYWLAN=wlan0 # Network interface name = wlan0 / wlan1
IPV6AGM=stable-privacy # IPv6 address status mode = stable-privacy / eui64
# Add WLAN
nmcli connection add \
con-name $MYCON \
type wifi \
ifname $MYWLAN \
autoconnect yes \
ipv6.addr-gen-mode $IPV6AGM \
wifi.ssid $MYSSID \
wifi-sec.key-mgmt $MYWSKM \
wifi-sec.psk $MYPSWD
nmcli connection up $MYCON
ip -c -br address
Modify the WiFi SSID or PASSWD
in the wireless network connection ssid
and take effect immediately.
# Set ENV
MYCON=ssid # Wireless network connection name
MYSSID=ssid # WiFi SSID, case sensitive
MYPSWD=passwd # WiFi password
MYWSKM=wpa-psk # Security selection WPA-WPA2 = wpa-psk or WPA3 = sae
# Add WLAN
nmcli connection modify $MYCON \
wifi.ssid $MYSSID \
wifi-sec.key-mgmt $MYWSKM \
wifi-sec.psk $MYPSWD
nmcli connection up $MYCON
ip -c -br address
Modify the IP address allocation method to Static IP address
on the network connection ether1
and take effect immediately.
*Applicable to wired connections / wireless connections
# Set ENV
MYCON=ether1 # Network connection name
IP=192.168.67.167/24 # HOST IP address, where 24 is the subnet mask corresponding to 255.255.255.0
GW=192.168.67.1 # Gateway
DNS=119.29.29.29,223.5.5.5 # DNS server address
# Chg CON
nmcli connection modify $MYCON \
ipv4.method manual \
ipv4.addresses $IP \
ipv4.gateway $GW \
ipv4.dns $DNS
nmcli connection up $MYCON
ip -c -br address
Modify the IP address allocation method to DHCP Obtains Dynamic IP Address
on the network connection ether1
and take effect immediately.
*Applicable to wired connections / wireless connections
# Set ENV
MYCON=ether1 # Network connection name
# Chg CON
nmcli connection modify $MYCON \
ipv4.method auto \
ipv6.method auto
nmcli connection up $MYCON
ip -c -br address
Modify (clone) the MAC Address
on the network connection ether1
and take effect immediately to solve the problem of LAN MAC address conflict.
*Applicable to wired connections / wireless connections
# Set ENV
MYCON=ether1 # Network connection name, note to match the network interface type
MYTYPE=ethernet # Network interface type = Wired network card / Wireless network card = ethernet / wifi
MYMAC=12:34:56:78:9A:BC # New MAC address
# Chg CON
nmcli connection modify ${MYCON} \
${MYTYPE}.cloned-mac-address ${MYMAC}
nmcli connection up ${MYETH}
ip -c -br address
- When creating or modifying some network parameters, the network connection may be disconnected and reconnected to the network.
- Due to different software and hardware environments (box, system, network equipment, etc.), it takes about
1-15
seconds to take effect. If it does not take effect for a longer time, it is recommended to check the software and hardware environment.
You can use the nmcli
utility to disable the IPv6
protocol from the command line. Please refer to disable-ipv6 for the source.
Step 1, use the nmcli connection show
command to view the network connection list, and the returned result is as follows:
NAME UUID TYPE DEVICE
Wired connection 1 8a7e0151-9c66-4e6f-89ee-65bb2d64d366 ethernet eth0
...
Step 2, set the ipv6.method parameter of the connection to disabled:
nmcli connection modify "Wired connection 1" ipv6.method "disabled"
Step 3, reconnect to the network:
nmcli connection up "Wired connection 1"
Step 4, check the network connection status. If there is no inet6 entry displayed, IPv6 is disabled on the device:
ip address show eth0
Step 5, verify whether the /proc/sys/net/ipv6/conf/eth0/disable_ipv6
file now contains the value 1
# cat /proc/sys/net/ipv6/conf/eth0/disable_ipv6
1
Some devices support using wireless, the enablement method is as follows:
# Install management tool
sudo apt-get install network-manager
# Check network devices
sudo nmcli dev
# Enable wireless
sudo nmcli r wifi on
# Scan wireless
sudo nmcli dev wifi
# Connect to wireless
sudo nmcli dev wifi connect "wifi name" password "wifi password"
# Display the saved network connection list
sudo nmcli connection show
# Disconnect
sudo nmcli connection down "wifi name"
# Forget the connection and cancel automatic connection
sudo nmcli connection delete "wifi name"
Some devices support using Bluetooth, the enablement method is as follows:
# Install Bluetooth support
armbian-config >> Network >> BT: Install Bluetooth support
# Reboot the system
reboot
After the system reboots, check whether the Bluetooth driver is normal. The desktop system can connect Bluetooth devices from the menu. It can also be installed using the terminal graphical interface.
dmesg | grep Bluetooth
# Connect Bluetooth device
armbian-config >> Network >> BT: Discover and connect Bluetooth devices
You can also install it using commands in the terminal:
# Check the Bluetooth service running status
sudo systemctl status bluetooth
# If not started, start the Bluetooth service first
sudo systemctl enable bluetooth
sudo systemctl start bluetooth
# Scan nearby Bluetooth devices
bluetoothctl scan on
# Enable Bluetooth discovery
bluetoothctl discoverable on
# Pair the Bluetooth MAC address
bluetoothctl pair 12:34:56:78:90:AB
# Check the paired Bluetooth devices
blluetoothctl paired-devices
# Connect to the Bluetooth device
bluetoothctl connect 12:34:56:78:90:AB
# Trust the device for easy connection next time
bluetoothctl trust 12:34:56:78:90:AB
# Disconnect the Bluetooth device
bluetoothctl disconnect 12:34:56:78:90:AB
# Unpair the Bluetooth device
bluetoothctl remove 12:34:56:78:90:AB
# Block the connected device
bluetoothctl block 12:34:56:78:90:AB
A custom script for startup tasks has already been added to the system. In the Armbian system, the path is /etc/custom_service/start_service.sh. You can customize and add related tasks to this script according to your personal needs.
By using the armbian-sync
command, you can update all service scripts in the local system to the latest version with one click.
When we write the Armbian system into the eMMC system, we need to first confirm the Android system partition table of the device to ensure that data is written to a safe area. Try not to damage the Android system partition table to avoid problems such as the system not being able to start. If you write to an unsafe area, it may fail to start or display an error similar to the one below:
If you are using Armbian released in this repository after 2022.11, you can copy and paste the following command to obtain a URL that records the complete partition information (the device itself does not need to be connected to the internet):
ampart /dev/mmcblk2 --mode webreport 2>/dev/null
The webreport mode of ampart was introduced in the v1.2 version released on 2023.02.03. If there is no output when you use the above command, it may be an older version that does not support directly outputting URLs. You can instead use the following command:
echo "https://7ji.github.io/ampart-web-reporter/?dsnapshot=$(ampart /dev/mmcblk2 --mode dsnapshot 2>/dev/null | head -n 1)&esnapshot=$(ampart /dev/mmcblk2 --mode esnapshot 2>/dev/null | head -n 1)"
The URL you obtain will look similar to the one below:
https://7ji.github.io/ampart-web-reporter/?esnapshot=bootloader:0:4194304:0%20reserved:37748736:67108864:0%20cache:113246208:754974720:2%20env:876609536:8388608:0%20logo:893386752:33554432:1%20recovery:935329792:33554432:1%20rsv:977272832:8388608:1%20tee:994050048:8388608:1%20crypt:1010827264:33554432:1%20misc:1052770304:33554432:1%20instaboot:1094713344:536870912:1%20boot:1639972864:33554432:1%20system:1681915904:1073741824:1%20params:2764046336:67108864:2%20bootfiles:2839543808:754974720:2%20data:3602907136:4131389440:4&dsnapshot=logo::33554432:1%20recovery::33554432:1%20rsv::8388608:1%20tee::8388608:1%20crypt::33554432:1%20misc::33554432:1%20instaboot::536870912:1%20boot::33554432:1%20system::1073741824:1%20cache::536870912:2%20params::67108864:2%20data::-1:4
Copy and paste this URL into your browser to view the clear and concise DTB partition information and eMMC partition information:
When you need to share partition information with others (for example, posting to this repository to report on a new device, or seeking help from others), try to share the URL itself rather than a screenshot. If you mind the URL being too long, you can use some free short URL tools.
- On the one hand, the partition information on the webpage is dynamically generated each time you visit. The annotation of whether certain partitions can be written to and the format of the table may be updated.
- On the other hand, others cannot conveniently copy partition parameters from screenshots for calculations, etc.
Also, you don't need to manually organize parameters into a table file. The layout of the table on the webpage has been specifically designed to be easily copied and pasted into Excel or LibreOffice Calc.
The DTB table records the partition layout that every box's system hopes for in Android DTB. This layout usually ends with a data
partition of automatically filled size, so boxes of the same system (and therefore, the same model) will necessarily have the same layout here. The actual partition layout on the box may vary due to different eMMC capacities, but it is always determined by the DTB partition layout (i.e., given the DTB partition layout and the exact size of eMMC, the eMMC partition situation can be deduced. Did you notice that the above DTB partition information and eMMC partition information do not come from the same box?).
The eMMC table is the actual eMMC partition layout on the box. Each row represents a storage area, which could be a partition or a gap between partitions (due to Amlogic's quirky decision, there is at least an 8M gap between each partition, which was intended to be used for other purposes, but hasn't been used even in the latest S905X4, wasting space). In the row corresponding to a partition, the font is black, and both the offset and mask columns have values. In the row corresponding to a gap, the font is grey, the offset and mask columns have no values, and the partition name is gap
.
In the eMMC table, the last column of each storage area indicates whether it can be written to. Green and yes
mean the area can be written to, red and no
mean the area absolutely cannot be written to, and yellow with a label indicates it can be written to under certain prerequisites, or only part of it can be written to.
Using the above table as an example, the 0+4M
(0M~4M
) area corresponding to the bootloader
partition absolutely cannot be written to, the 32M
gap (4M~36M
) after it can be written to, the 36M+64M
(36M~100M
) area corresponding to the reserved
partition absolutely cannot be written to, the gap from there to the gap before env
(100M~836M
) can all be written to, the 1M after env
(837M to the end
) can be written to in case the Android boot logo is not needed, then the writable range on eMMC is:
- 4M~36M
- 100M~836M
- 837M~end
If the Android boot logo is needed, additionally, the 852M + 32M (852M~884M
) area corresponding to the logo
partition cannot be written to, then the writable range on eMMC is:
- 4M~36M
- 100M~836M
- 837M~852M
- 884M~end
If your device fails when using armbian-install
and the -a
parameter (use ampart to adjust the eMMC partition layout) is yes
(default value), then your box cannot use the optimal layout (that is, adjust the DTB partition information to only have data
, then generate eMMC partition information from this, and then move all remaining partitions forward. In this way, the space from 117M onwards can be used). You need to modify the corresponding partition information in armbian-install.
In this file, the key parameters for declaring the partition layout are three: BLANK1
, BOOT
, BLANK2
. Among them, BLANK1
represents the unusable size starting from the beginning of eMMC; BOOT
represents the size of the partition created after BLANK1
for storing the kernel, DTB, etc., preferably not less than 256M, BLANK2
represents the unusable size after BOOT
. The space after this will be used to create the ROOT
partition to store all the data outside the /boot
mount point in the system. All three should be integers, and the unit is MiB (1 MiB = 1024 KiB = 1024^2 Byte)
In the case discussed in the previous paragraph where the logo
partition is not needed, we naturally hope to use all the usable space, but the area of 4M~36M
is too small to be used as BOOT
, so it can only be counted in the unusable BLANK1
. The area of 100M~836M
is more than enough to be used as BOOT
, so this 736M can be allocated to BOOT
entirely. After this, there is an unusable area of 836M~837M
, which is given to BLANK2
, so the parameters to be used should be as follows (only s905x3
is used as an example in the following text, if your SoC is other, you need to modify other corresponding code blocks):
# Set partition size (Unit: MiB)
elif [[ "${AMLOGIC_SOC}" == "s905x3" ]]; then
BLANK1="100"
BOOT="736"
BLANK2="1"
The u-boot file is a crucial component for the proper startup of the system. The process of obtaining source code and the compilation workflow varies slightly for Amlogic, Allwinner, and Rockchip devices.
Due to the fact that most manufacturers of Amlogic devices keep their source code closed, we need to extract u-boot related files from the device before proceeding with compilation. The method presented here is derived from the production tutorial shared by unifreq.
Extraction requires the HxD software. You can get the installation from the official download link or the backup download link.
Execute the following commands one by one in the cmd
panel to extract the relevant files and download them to your local computer.
# Use adb tool to enter the box
adb connect 192.168.1.111
adb shell
# Export bootloader command
dd if=/dev/block/bootloader of=/data/local/bootloader.bin
# Export dtb command
cat /dev/dtb >/data/local/mybox.dtb
# Export gpio command
cat /sys/kernel/debug/gpio >/data/local/mybox_gpio.txt
# Download the bootloader, dtb, and gpio files to the root directory of the C drive on your local computer in the mybox folder
adb pull /data/local/bootloader.bin C:\mybox
adb pull /data/local/mybox.dtb C:\mybox
adb pull /data/local/mybox_gpio.txt C:\mybox
The most important part of the mainline u-boot is the acs.bin, which is used to initialize part of the memory. The original factory u-boot is located at the very front of the system, at a 4MB position. Use the bootloader.bin
file obtained just now to extract the acs.bin
file.
Open the HxD software, open the exported bootloader.bin
file, Right click - Select range
, start position F200
, length 1000
, select hexadecimal
.
Copy the selected result, then create a new file, paste in insert mode, ignore the warning, and save it as the acs.bin file.
If the bootloader is locked, the code in this area is garbled and useless. Normally, there should be many 0
s as in the picture above, cfg
will appear several times in succession, and ddr
related words will appear in the middle. This normal code can be used.
Creating u-boot requires source repositories https://github.com/unifreq/amlogic-boot-fip and https://github.com/unifreq/u-boot to compile two u-boot files for your device.
Within the amlogic-boot-fip source code, the only file that varies by device model is acs.bin, all other files are universal.
For instructions on creating u-boot, see the specific instructions in https://github.com/unifreq/u-boot/tree/master/doc/board/amlogic, and choose your device model for compiling and testing.
Creating u-boot according to unifreq's method requires the use of the device's acs.bin, dts, and config files. The dts exported from the Android system cannot be directly converted into the Armbian format, so you need to write a corresponding dts file yourself. Based on the specific differences in hardware on your device, such as switches, LEDs, power control, TF card, SDIO wifi module, etc., modify and create a dts file from the similar ones in the kernel source repository.
For example, creating a u-boot for X96Max Plus:
~/make-uboot
├── amlogic-boot-fip
│ ├── x96max-plus # Create directory yourself
│ │ ├── asc.bin # Self-made source file
│ │ └── other-copy-files... # Copy files from other directories
│ │
│ ├── other-source-directories...
│ └── other-source-files...
│
└── u-boot
├── configs
│ └── x96max-plus_defconfig # Self-made source file
├── arch
│ └── arm
│ └── dts
│ ├── meson-sm1-x96-max-plus-u-boot.dtsi # Self-made source file
│ ├── meson-sm1-x96-max-plus.dts # Self-made source file
│ └── Makefile # Edit
├── fip
│ ├── u-boot.bin # Generated file
│ └── u-boot.bin.sd.bin # Generated file
├── u-boot.bin # Generated file
│
├── other-source-directories...
└── other-source-files...
- Download the amlogic-boot-fip source code. In the root directory, create a x96max-plus directory. Other than the
asc.bin
file that you created, all other files can be copied from other directories. - Download the u-boot source code. Create a corresponding x96max-plus_defconfig file and put it into the configs directory. Create the corresponding meson-sm1-x96-max-plus-u-boot.dtsi and meson-sm1-x96-max-plus.dts files and put them in the arch/arm/dts directory, then edit the Makefile in this directory to add the
meson-sm1-x96-max-plus.dtb
file index. - In the root directory of the u-boot source code, follow the steps in the document https://github.com/unifreq/u-boot/blob/master/doc/board/amlogic/x96max-plus.rst.
Two types of files are ultimately generated: the u-boot.bin
file in the u-boot root directory is an incomplete version of u-boot used in the /boot
directory (corresponds to the overload directory in the repository); the u-boot.bin
and u-boot.bin.sd.bin
in the fip
directory are complete versions of u-boot files used in the /usr/lib/u-boot/
directory (corresponds to the bootloader directory in the repository). The complete versions of the two files differ by 512 bytes, the larger one has 512 bytes of 0 filled in front.
💡 Tip: Before writing to eMMC for testing, please refer to section 12.3 for unbricking methods. Be sure to understand the short circuit point location, have the original .img format Android system file, and have performed short-circuit flashing tests. Ensure that you have mastered all the unbricking methods before proceeding with writing tests.
Since most manufacturers of Rockchip devices have opened up their u-boot source code, it's relatively easy to obtain the relevant u-boot source code from the manufacturer's source code repository and proceed with the compilation. Additionally, some open-source enthusiasts have also shared numerous user-friendly u-boot compilation scripts. Below, I'll provide a few examples to illustrate various compilation methods.
Taking compiling Rock5b(rk3588) as an example.
# 01.Install the necessary build dependencies
sudo apt-get update
sudo apt-get install -y git device-tree-compiler libncurses5 libncurses5-dev build-essential libssl-dev mtools bc python dosfstools flex bison
# 02.Set up your workspace and get the source code from the Radxa Git repositories
mkdir ~/rk3588-sdk && cd ~/rk3588-sdk
git clone -b stable-5.10-rock5 https://github.com/radxa/u-boot.git
git clone -b master https://github.com/radxa/rkbin.git
git clone -b debian https://github.com/radxa/build.git
# Explanation of the source code:
# ~/rk3588-sdk/build/: Radxa helper script files and configuration files for building U-Boot, Linux kernel and rootfs.
# ~/rk3588-sdk/rkbin/: Pre-built Rockchip binaries, including first stage loader and ATF (Arm Trustzone Firmware)
# ~/rk3588-sdk/u-boot/: Second stage bootloader used to start the OS (e.g. Linux or Android)
# 03.Build u-boot (For ROCK 5B)
cd ~/rk3588-sdk
./build/mk-uboot.sh rk3588-rock-5b
# 04.After a successful build, the ~/rk3588-sdk/out/u-boot directory will be populated
~/rk3588-sdk/out/u-boot
├── idbloader.img
├── rk3588_spl_loader_v1.08.111.bin
├── spi
│ └── spi_image.img
└── u-boot.itb
By adding more options in the board_configs.sh
and mk-uboot.sh
within the radxa/build source code, it's possible to compile u-boot files for other devices as well. For instance, you can follow the instructions provided for compiling the Beelink-IPC-R(rk3588) device.
cm9vdA provides scripts and usage instructions for compiling u-boot and the kernel in his open-source project cm9vdA/build-linux. I have utilized his project for u-boot compilation in various Rockchip devices and documented the processes for reference. Here are some excerpts:
- Build u-boot for Lenovo-Leez-P710 (rk3399) device: Link
- Build u-boot for DLFR100 (rk3399) device: Link
- Build u-boot for ZYSJ (rk3399) device: Link
If the memory size is recognized incorrectly (it is abnormal for 4G memory to be recognized as 1-2G, and it is normal to be recognized as 3.7G), you can try to manually copy a /boot/UBOOT_OVERLOAD
file (please note it's "copy", "do not rename", as renaming it will make the system unable to boot after installation and updates). When used in USB
, save it as /boot/u-boot.ext
, and when used in eMMC
, save it as /boot/u-boot.emmc
.
Apart from trying to solve memory problems, do not manually copy the u-boot file. Incorrect addition will cause the system to fail to boot and various problems to occur.
Some new devices are not currently supported (or have variants), and you can try to adjust related parameters by decompiling.
# Install dependencies
sudo apt-get update
sudo apt-get install -y device-tree-compiler
# 1. Decompilation command (generate dts source code using dtb file)
dtc -I dtb -O dts -o xxx.dts xxx.dtb
# 2. Compilation command (generate dtb file using dts)
dtc -I dts -O dtb -o xxx.dtb xxx.dts
# 3. Save data and reboot
sync && reboot
# 4. [Optional action] Perform testing based on requirements
# e.g., reinstall for testing when addressing the issue mentioned in 12.16
armbian-install
In Amlogic devices, you can add/modify/delete settings in the /boot/uEnv.txt
file. In Rockchip and Allwinner devices, you can set in the /boot/armbianEnv.txt
file (add to extraargs
or extraboardargs
parameters). Devices using /boot/extlinux/extlinux.conf
configure in this file. You need to restart after each change for it to take effect.
-
For instance, the
Home Assistant Supervisor
application only supports thedocker cgroup v1
version, while the currently default installed version for Docker is the latest v2. If you need to switch to the v1 version, you can add thesystemd.unified_cgroup_hierarchy=0
parameter setting in cmdline. After restarting, you can switch to thedocker cgroup v1
version. -
By adding
max_loop=128
in cmdline, you can adjust the allowable amount of loop mounts. -
By adding
usbcore.usbfs_memory_mb=1024
in cmdline, you can permanently change the USBFS memory buffer from the default16 mb
to larger (cat /sys/module/usbcore/parameters/usbfs_memory_mb
), improving the ability to transfer large files over USB. -
By adding
usbcore.usb3_disable=1
in cmdline, you can disable all USB 3.0 devices.
To build an Armbian system for a device, you need to use the device configuration file
, system file
, u-boot file
, and process control file
. The specific addition methods are introduced as follows:
In the configuration file /etc/model_database.conf, add the corresponding configuration information according to the device's test support status. The BUILD
value is yes
for some default build devices, the corresponding BOARD
value must be unique
, these boxes can use the default built Armbian system directly.
The default value is no
without packaging, these devices need to download the same FAMILY
Armbian system when using, after writing to USB
, you can open USB's boot partition
on your computer, modify the FDT dtb name
in /boot/uEnv.txt
file, adapt to other devices in the list.
Common files are placed in the build-armbian/armbian-files/common-files
directory, universally applicable across platforms.
Platform files are respectively placed in build-armbian/armbian-files/platform-files/<platform>
directory, Amlogic, Rockchip, and Allwinner share files of their respective platforms. The bootfs
directory contains /boot partition files, and the rootfs
directory contains Armbian system files.
If individual devices have special differential setting requirements, add an independent directory named after BOARD
in the build-armbian/armbian-files/different-files
directory, create bootfs
directory as needed to add related files under system /boot
partition, create rootfs
directory as needed to add system files. All folder names are based on the actual path in the Armbian
system. Used to add new files, or to override the same name files added from the common files and platform files.
Amlogic
series devices, share bootloader files and u-boot files. If there are new files, put them in the corresponding directory. The bootloader
files will automatically be added to the Armbian system's /usr/lib/u-boot
directory during system construction, and u-boot
files will be automatically added to the /boot
directory.
Rockchip
and Allwinner
series devices, add an independent u-boot file directory named after BOARD
for each device, and the corresponding series files are placed in this directory.
During the Armbian image construction, these u-boot files will be written into the corresponding Armbian image files by the rebuild script according to the configuration in /etc/model_database.conf.
Add the corresponding BOARD
option to armbian_board
in the yml workflow control file, which supports use in Actions
on github.com.
Some devices can normally boot Armbian from USB/SD/TF, but when writing to eMMC, an I/O write error is reported, such as the case in Issues, with the following error message:
[ 284.338449] I/O error, dev mmcblk2, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[ 284.341544] Buffer I/O error on dev mmcblk2, logical block 0, lost async page write
[ 284.446972] I/O error, dev mmcblk2, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[ 284.450074] Buffer I/O error on dev mmcblk2, logical block 0, lost async page write
[ 284.497746] I/O error, dev mmcblk2, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
[ 284.500871] Buffer I/O error on dev mmcblk2, logical block 0, lost async page write
In such a situation, you can adjust the working mode speed and frequency of the dtb being used to stabilize the read and write support for storage. When using sdr mode, the frequency is twice the speed. When using ddr mode, the frequency equals the speed. For example:
sd-uhs-sdr12
sd-uhs-sdr25
sd-uhs-sdr50
sd-uhs-ddr50
sd-uhs-sdr104
max-frequency = <208000000>;
Take the code snippet in the dts file of the kernel source code as an example:
/* SD card */
&sd_emmc_b {
status = "okay";
bus-width = <4>;
cap-sd-highspeed;
sd-uhs-sdr12;
sd-uhs-sdr25;
sd-uhs-sdr50;
max-frequency = <100000000>;
};
/* eMMC */
&sd_emmc_c {
status = "okay";
bus-width = <8>;
cap-mmc-highspeed;
max-frequency = <100000000>;
};
Generally, reducing the frequency of &sd_emmc_c
from max-frequency = <200000000>;
to max-frequency = <100000000>;
can solve the problem. If it doesn't work, you can continue to reduce it to 50000000
for testing, and adjust &sd_emmc_b
to set USB/SD/TF
, you can also use sd-uhs-sdr
to limit speed. You can modify the dts file and compile to get the test file, or you can use the method introduced in Section 12.13
to decompile and modify the existing dtb file to generate the test file. When modifying the decompiled dtb file, use hexadecimal values, where the decimal 200000000
corresponds to the hexadecimal 0xbebc200
, the decimal 100000000
corresponds to the hexadecimal 0x5f5e100
, the decimal 50000000
corresponds to the hexadecimal 0x2faf080
, and the decimal 25000000
corresponds to the hexadecimal 0x17d7840
.
In addition to solving this issue through the system software layer, it can also be resolved through money ability and hands-on ability.
Error log information for the sound issue:
Mar 29 15:47:18 armbian-ct2000 kernel: fe.dai-link-0: ASoC: dpcm_fe_dai_prepare() failed (-22)
Mar 29 15:47:18 armbian-ct2000 kernel: fe.dai-link-0: ASoC: no backend DAIs enabled for fe.dai-link-0
Please refer to the method in Bullseye NO Sound for settings.
curl -fsSOL https://github.com/ophub/kernel/releases/download/tools/bullseye_g12_sound-khadas-utils-4-2-any.tar.gz
tar -xzf bullseye_g12_sound-khadas-utils-4-2-any.tar.gz -C /
systemctl enable sound.service
systemctl restart sound.service
Restart Armbian for testing. If the sound still doesn't work, it may be because your box is using the old conf corresponding to the sound output route. You need to comment out the new configuration corresponding to L137-L142
in /usr/bin/g12_sound.sh (mainly for G12B, that is, S922X, before the old G12A/S905X2, and most of the SM1/S905X3 based on G12A can't be used), and then uncomment the old configuration corresponding to L130-L134
.
In the Armbian system, the boot.scr
file in the /boot
directory is used for booting the system. boot.scr
is the compiled version of the boot.cmd
file. boot.cmd
is the source code file for boot.scr
. You can modify the boot.cmd
file to make changes to the boot.scr
file and then compile it into a boot.scr
file using the mkimage command.
Normally, these two files do not need to be modified. If adjustments are necessary, you can follow the methods below.
# Install dependencies
sudo apt-get update
sudo apt-get install -y u-boot-tools
# Edit the boot.cmd file
cd /boot
copy /boot/boot.cmd /boot/boot.cmd.bak
copy /boot/boot.scr /boot/boot.scr.bak
nano boot.cmd
# Compile the boot.scr file
mkimage -C none -A arm -T script -d boot.cmd boot.scr
# Restart to test
sync
reboot
# Additional Explanation
# For Amlogic devices, the file used in USB is /boot/boot.scr, while the file used for writing to eMMC is /boot/boot-emmc.scr.
In the software center armbian-software
, selecting 201
allows you to install a desktop. When installing the desktop, you will be asked whether to enable the remote desktop, input y
to enable. The default port for the remote desktop is 3389
, and you can use a custom port according to your needs:
sudo nano /etc/xrdp/xrdp.ini
# Change to a custom port, for example 5000
port=5000