Translation(s): none

Models covered
SolidRun ClearFog

• ClearFog Base, smaller model featuring only 2 Ethernet connectors

• ClearFog Pro, larger model featuring one Ethernet connector and a five-port switch

Overall Status

Legend :
= OK ; Unsupported(No Driver) ; = Error (Couldn't get it working); [?] Unknown, Not Test ; [-] Not-applicable
= Configuration Required; = Only works with a non-free driver and or firmware

Important Note

THis page is under creation. Until finished also take a look at https://weblog.siccegge.de/Running_Debian_on_the_ClearFog.html

Both ClearFog models are available with eMMC and without. The versions with EMMC cannot be used with an μSD card and are in general more troublesom to set up and operate. Be sure to know which version you have.

Only the ClearFog Base with eMMC has been tested so far.

Configuration

While upstream support is, in general, quite good, it covers mostly the ClearFog Pro with μSD. We will cover adjustments for eMMC and the Base version separately from the general support part.

Kernel

The unstable / stretch armhf armmp kernel fully supports the devices. As all drivers are built as modules for this kernel, a initrd is needed to boot and it seems this initrd needs to be in uImage format. Building an upstream kernel with mvebu_v7_defconfig gets around this if needed. Some CPU powersaving options are currently marked as broken and disable in the mainline kernel.

U-Boot

The unstable / stretch version of U-Boot source supports the device. However no binary is built currently (but certainly could be built if someone with a PRO + μSD device is willing to test and confirm it works). It can, however, be easily built with clearfog_defconfig.

flash-kernel

flash-kernel is the part responsible for creating the uImages and configuring U-Boot to load the right kernel. ClearFog support is work in progress on the flash-kernel pacakge, see 839595.

UART Boot

If the bootloader you installed no longer works, the ClearFog can be unbricked via UART booting (It then loads the bootloader via the xmodem protocol). Doing so is actually pretty easy with the help of the kwboot utility once you have a (mainline) u-boot binary:

kwboot -b u-boot-spl.kwb -t -p /dev/ttyUSB0

This should work, however UART mode detection in U-Boot SPL was broken on the tested device and got the wrong magic number in the boot register. This can easily be fixed with the following patch (the resulting U-Boot will no longer work for any other boot option though!):

--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -28,7 +28,7 @@ static u32 get_boot_device(void)
        val = readl(CONFIG_BOOTROM_ERR_REG);
        boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
        debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
-       if (boot_device == BOOTROM_ERR_MODE_UART)
+       //if (boot_device == BOOTROM_ERR_MODE_UART)
                return BOOT_DEVICE_UART;
 
        /*

Networking

Without further setup, no network will be available in U-Boot and Linux. You need to manually configure MAC addresses for the three interfaces with the U-Boot commands below (replace XX:XX:XX:XX:XX:XX with the desired MAC Address). After a saveenv and reset networking will be fully functional.

setenv eth1addr XX:XX:XX:XX:XX:XX
setenv eth2addr XX:XX:XX:XX:XX:XX
setenv eth3addr XX:XX:XX:XX:XX:XX

ClearFog Base

The Base is pretty similar to the Pro version. However, both U-Boot and Linux device tree files assume that the second ethernet port is wired to the switch chip which makes it non-functional on the Base. If you want to use it you'll need to patch the device-tree for U-Boot and/or the kernel. The patch for U-Boot:

--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -89,13 +89,10 @@
        internal-regs {
            ethernet@30000 {
                mac-address = [00 50 43 02 02 02];
+              managed = "in-band-status";
+              phy = <&phy1>;
                phy-mode = "sgmii";
                status = "okay";
-
-              fixed-link {
-                  speed = <1000>;
-                  full-duplex;
-              };
            };

            ethernet@34000 {
@@ -227,6 +224,10 @@
                pinctrl-0 = <&mdio_pins>;
                pinctrl-names = "default";

+              phy1: ethernet-phy@1 { /* Marvell 88E1512 */
+                   reg = <1>;
+              };
+
                phy_dedicated: ethernet-phy@0 {
                    /*
                     * Annoyingly, the marvell phy driver
@@ -386,62 +386,6 @@
        tx-fault-gpio = <&expander0 13 GPIO_ACTIVE_HIGH>;
    };

-  dsa@0 {
-      compatible = "marvell,dsa";
-      dsa,ethernet = <&eth1>;
-      dsa,mii-bus = <&mdio>;
-      pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
-      pinctrl-names = "default";
-      #address-cells = <2>;
-      #size-cells = <0>;
-
-      switch@0 {
-          #address-cells = <1>;
-          #size-cells = <0>;
-          reg = <4 0>;
-
-          port@0 {
-              reg = <0>;
-              label = "lan1";
-          };
-
-          port@1 {
-              reg = <1>;
-              label = "lan2";
-          };
-
-          port@2 {
-              reg = <2>;
-              label = "lan3";
-          };
-
-          port@3 {
-              reg = <3>;
-              label = "lan4";
-          };
-
-          port@4 {
-              reg = <4>;
-              label = "lan5";
-          };
-
-          port@5 {
-              reg = <5>;
-              label = "cpu";
-          };
-
-          port@6 {
-              /* 88E1512 external phy */
-              reg = <6>;
-              label = "lan6";
-              fixed-link {
-                  speed = <1000>;
-                  full-duplex;
-              };
-          };
-      };
-  };
-
    gpio-keys {
        compatible = "gpio-keys";
        pinctrl-0 = <&rear_button_pins>;

eMMC version

Just to repeat it: the eMMC version will not be able to access the μSD Card (though it has the connector). There are three principal difficulties with the eMMC version: It does not come with any bootloader preinstalled so fallback to UART booting seems necessary; it needs patching the device tree to detect the flash; and it has somewhat different offsets for U-Boot SPL.

In a nutshell, the eMMC is connected to the same PINs as the μSD would be. However there's a final PIN which tells whether a μSD card is inserted or not. This PIN is not connected on the eMMC version and is wired permanently in the "card absent" state. The solution for Kernel and U-Boot to speak to eMMC is removing that PIN definition from the device tree. Path for U-Boot:

--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -306,7 +307,6 @@
 
                        sdhci@d8000 {
                                bus-width = <4>;
-                               cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
                                no-1-8-v;
                                pinctrl-0 = <&clearfog_sdhci_pins
                                             &clearfog_sdhci_cd_pins>;

The part with the offsets is somewhat more difficult. The μSD version will start loading U-Boot from the second sector of the card, while it will load the first sector from the special mmcblk0boot0 label for eMMC. This results in an off-by-one-block when the SPL loads the main U-Boot binary. Fixing this offset will make the SPL happy but main U-Boot will still fail -- it seems to be reading from the "normal" mmcblk0 which consequently needs to have a properly located U-Boot binary as well. Running the following two commands will provide U-Boot everywhere needed:

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=u-boot-spl.kwb of=/dev/mmcblk0boot0 bs=512
dd if=u-boot-spl.kwb of=/dev/mmcblk0 bs=512 seek=1 skip=1

The first part is needed to make the special mmcblk0boot0 writeable, the second will install U-Boot where the firmware and the SPL expect it and the third will make sure it's also found in later stages. The seek=1 skip=1 will make sure your MBR stays untouched while the offsets are still the same as on the boot0 device. Finally to build the u-boot-spl.kwb the following patch can be used:

--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -143,8 +143,7 @@
 #define CONFIG_SPL_LIBDISK_SUPPORT
 #define CONFIG_SYS_MMC_U_BOOT_OFFS             (160 << 10)
 #define CONFIG_SYS_U_BOOT_OFFS                 CONFIG_SYS_MMC_U_BOOT_OFFS
-#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR        ((CONFIG_SYS_U_BOOT_OFFS / 512)\
-                                                + 1)
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR        (CONFIG_SYS_U_BOOT_OFFS / 512)
 #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS     ((512 << 10) / 512) /* 512KiB */
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_FIXED_SDHCI_ALIGNED_BUFFER      0x00180000      /* in SDRAM */

Power Consumption

ClearFog Base has been measured to consume around 5.5 W in idle and around 8 W under load.

lspci

# lspci -nn
00:02.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6828] (rev 04) (prog-if 00 [Normal decode])
        Flags: fast devsel
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Prefetchable memory behind bridge: 00000000-000fffff
        Capabilities: [40] Express Root Port (Slot+), MSI 00

00:03.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6828] (rev 04) (prog-if 00 [Normal decode])
        Flags: fast devsel
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        Prefetchable memory behind bridge: 00000000-000fffff
        Capabilities: [40] Express Root Port (Slot+), MSI 00

lsusb

lsusb -v | grep -E '\<(Bus|iProduct|bDeviceClass|bDeviceProtocol)' 2>/dev/null
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         3 
  iProduct                2 xHCI Host Controller
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         1 Single TT
  iProduct                2 xHCI Host Controller
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         3 
  iProduct                2 xHCI Host Controller
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         1 Single TT
  iProduct                2 xHCI Host Controller
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         1 Single TT
  iProduct                2 EHCI Host Controller

Resources

Attachments

Some configuration files and sample outputs.

Useful Links

Credits

CategoryDebianOn CategoryDebianOn