According to Global Scale, the ESPRESSObin boards can support at least some OEM mPCIe WiFi cards if the relevent configuration is set up and the kernel is rebuilt. Our project does not require WiFi, as all planned connections will be wired.
When mPCIe was first developed (around 2010), some OEMs built mPCIe SSD devices of low capacity and high cost. There boards are now obsolete and no longer available.
When the ESPRESSObin board boots up, the UBOOT firmware checks the mPCIe. If no compatible device is present, UBOOT reports “PCIE-0 Link down”. If a valid mPCIe board e.g. WiFi, UBOOT reports “PCIE-0 Link up”.
With a valid mPCIe device installed, when linux boots up, the mPCIe driver is loaded.
There are available SSD boards (e.g. 64 – 256 GB) that are not mPCIe, but rather mSATA devices that use the same connector, with different electrical parameters and signals. mSATA itself was superseded around 2018 by the M.2 SATA format with a different connector, signals, plus higher capacity and speed.
While an mSATA board can be installed, it is not recognized by UBOOT and consequently reports “PCIE-0 Link down”.
There are SATA <– mSATA to adapter boards that allow the mSATA card to be connected to the V4 board with cables, and plug directly into the V7 board.
Poking around the default 4.4.52 build kernel shows that no PCIe device is identifiable, so the driver is not being loaded by the kernel during the boot process. This is because the mPCIe bus is not activated by the presence of a compatible device.
The relevent 4.4.52 kernel source file …
has to be updated to correctly identify mPCIe devices, incorporated into the new kernel, and written to the ESPRESSObin board.
The kernel build is controlled by the .config file. Examination of this file (and after reading various discussions on-line) shows that it contains the commented line
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
which needs to be updated to
to enable the PCIe driver in the kernel.
Another Non Volatile MEmory relevent entry CONFIG_BLK_DEV_NVME=y is already present.
The redevelopment work is done on the Ubuntu 20.4 LST laptop used to create the SD card.
Preparing the build PC
$ sudo apt install git
This presents a ttf-mscorefonts-installer with [OK]. Hit TAB to select the [OK] then Enter to complete the installation.
Kernel version 4.4.52.
Create the directory into which the kernel will be cloned (e.g. /home/user/kernel/4.4.52/) and position there:
$ mkdir -p kernel/4.4.52 && cd kernel/4.4.52/
Clone the linux-marvell repository:
$ git clone https://github.com/MarvellEmbeddedProcessors/linux-marvell .
Create a new branch espressobin-v7 that uses a commit from the linux-4.4.52-armada-17.10 branch as a starting point:
$ git checkout 6adee55d3e07e3cc99ec6248719aac042e58c5e6 -b espressobin-v7
The 4.4.52 kernel source code tree to be used is now installed in
kernel/4.4.52/arch/arm64 which is the ESPRESSOBIN cpu type.
Note that many other hardware architecture files are in kernel/4.4.52/arch.
A series of patches needs to be applied for kernel version 4.4.52, branches linux-4.4.52-armada-17.06 and onward. These patches address the changes required for ESPRESSObin v7 hardware revision, as well as ensure backward compatibility with previous ESPRESSObin revisions (v5 and older).
The archive containing the patches can be downloaded below:
Extract the archive with:
$ unzip ebin_v7_kernel_patches.zip
Apply the patches using the git am command:
$ git am *.patch
Set the correct definitions for ARCH and CROSS_COMPILE variables:
$ export ARCH=arm64
$ export CROSS_COMPILE=aarch64-linux-gnu-
These two export commands are required for the next command
Next, create a default .config file using the arch/arm64/configs/mvebu_v8_lsp_defconfig file:
$ make mvebu_v8_lsp_defconfig
In the above command, make needs to use the gcc compiler. If it cannot be located (not installed or not in the PATH environment) it will have to be installed.
If the process is successful, the response is
# # configuration written to .config #
Custom features can be added using the menuconfig interface which is triggered via make menuconfig command.
Building uses the CROSS_COMPILE parameter (above) to build the ESPRESSObin kernel. To be clear, this is NOT a version of gcc toolchain that build Intel-compatible code.
Test if the the CROSS_COMPILE gcc is available.
$ echo $PATH | aarch64-linux-gnu-gcc
What this should do, and may not, is run the compiler and report no source files specified. The issue is fixed by installing the correct compiler.
$ sudo get install gcc-aarch64-linux-gnu
With the latest (Sept 2021) compiler there is a warning to be fixed in linux/include/log2.h
extern __attribute__((const)) // was ((const, noreturn))
If the correct compiler is present, start the build with:
$ make -j4
After a successful build (a full build takes around 20 minutes, incremental build about 5 minutes), you will find the kernel image ( Image ) in arch/arm64/boot/ directory. The device tree files for different ESPRESSObin hardware revisions have been generated in arch/arm64/boot/dts/marvell/ directory.
For ESPRESSObin v7 use the file armada-3720-community-v7.dtb and for ESPRESSObin v5 and older revisions use the armada-3720-community-v5.dtb device tree file.
The default boot .dtb is set via the Marvell>> setenv and saveenv commands e.g.
Marvell>> setenv fdt_name boot/armada-3720-community.dtb Marvell>> saveenv // the boot environment is written to firmware. You can also check the current value e.g. Marvell>> echo $fdt_name Test builds and tests for our ESPRESSObin v4 board show the same operation with armada-3720-community.dtb and armada-3720-community-v5.dtb so we are now working with the v5 dtb.
More to add soon.
Copyright © 2020-2022 PiXCL Automation Technologies Inc., Canada. All Rights Reserved.