Differences between revisions 5 and 11 (spanning 6 versions)
Revision 5 as of 2016-10-24 18:19:39
Size: 9906
Comment: += Image
Revision 11 as of 2016-10-24 19:02:26
Size: 14128
Comment: += vendor wiki link
Deletions are marked like this. Additions are marked like this.
Line 49: Line 49:
Base version separately from the general support part. Base version separately from the general support part. With upstream
U-Boot and Kernel support even d-i support should be doable given a
test device with μSD.

== 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}}}.

== Debian ==

For μSD, you can prepare a card quite the normal way. The U-Boot
binary goes at offset 1 ({{{dd bs=512 seek=1}}}). Leave enough space
before the first partition for U-Boot and the environment, 4 MiB
should be plenty. /boot/ needs to go on a filesystem U-Boot can
understand which rules out btrfs and ext4 with default options. A
separate /boot partition on ext3 works fine. The rest of the card can
then be used for a plain normal debootstrap root filesystem (and any
additional filesystems).

== 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 DebianBug:839595.

== 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
}}}-~
Line 82: Line 132:
== 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
}}}-~
Line 201: Line 237:
Line 204: Line 241:
bootloader preinstalled so fallback to UART booting seems necessary,
it needs patching the device tree to detect the flash and it has
bootloader preinstalled so fallback to UART booting seems necessary;
it needs patching the device tree to detect the flash; and it has
Line 207: Line 244:

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 */
}}}-~
Line 265: Line 360:
## Link to related installation-report
## Link to related bug(s) report(s)
## Avoid linking to other installation Howto from this page.
http://wiki.solid-run.com/doku.php?id=products:a38x:clearfog

DebianOn is an effort to document how to install, configure and use Debian on some specific hardware. Therefore potential buyers would know if that hardware is supported and owners would know how get the best out of that hardware.

The purpose is not to duplicate the Debian Official Documentation, but to document how to install Debian on some specific hardware.

If you need help to get Debian running on your hardware, please have a look at our user support channels where you may find specific channels (mailing list, IRC channel) dedicated to certain types of hardware.

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

Core Components

clearfog.jpg

Boot Standard Kernel:

{OK}

LAN network card (Generic Ethernet):

{OK}

SFP Module

[?]

Detect hard drives:

{OK}

CPU Frequency Scaling:

/!\

Legend :
{OK} = OK ; {X} Unsupported(No Driver) ; /!\ = Error (Couldn't get it working); [?] Unknown, Not Test ; [-] Not-applicable
{i} = Configuration Required; X-( = 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. With upstream U-Boot and Kernel support even d-i support should be doable given a test device with μSD.

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.

Debian

For μSD, you can prepare a card quite the normal way. The U-Boot binary goes at offset 1 (dd bs=512 seek=1). Leave enough space before the first partition for U-Boot and the environment, 4 MiB should be plenty. /boot/ needs to go on a filesystem U-Boot can understand which rules out btrfs and ext4 with default options. A separate /boot partition on ext3 works fine. The rest of the card can then be used for a plain normal debootstrap root filesystem (and any additional filesystems).

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.

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

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;
 
        /*

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.

  • [get | view] (2016-10-24 18:15:19, 223.1 KB) [[attachment:clearfog.jpg]]
 All files | Selected Files: delete move to page copy to page

http://wiki.solid-run.com/doku.php?id=products:a38x:clearfog

Credits



CategoryDebianOn CategoryDebianOn