Search the Community

Hello All, root:# hwclock --systohc root:# while true; do date; hwclock -r; sleep 60; done observing drift of 1 sec. even tried this https://github.com/armbian/build/pull/2352/commits/59cdf431ef691d67d649adbfaf973f9d451823bc#diff-dc13c5522aed383d1b20662d765c5be9f2635553256069dce64f29be94f89b69 specs: Armada 38x RTC driver ARM_GLOBAL_TIMER Board : Marvell Armada A385 DB AP Kernel : 4.14 community help will be grateful Regards Hardik

Not a feature request, I'm just curious about why things are like this. Context around the error message Line 170: tries to enable ACS but CONFIG_ACS disabled 1 errors found in configuration file '/etc/hostapd/hostapd-5.conf' Failed to set up interface with /etc/hostapd/hostapd-5.conf Failed to initialize interface Most relevant part of hostapd-5.conf ... hw_mode=any ... channel=acs_survey ... Probably the root cause of this $ apt source hostapd ... $ grep CONFIG_ACS wpa-2.10/hostapd/defconfig #CONFIG_ACS=y So my question is, why is CONFIG_ACS disabled when having Automatic Channel Selection (ACS) is useful? Thanks, KES

Hello, I've finally gotten around to writing the GitHub Actions based Linux Kernel Shallow git trees exporter. It's very simple, a single shell script and GHA workflow. It prepares shallow bundle (and ready-to-go .tar too) everyday on a schedule and publishes to GitHub Releases. Please take a look https://github.com/rpardini/armbian-git-shallow - theres a README that shows how to use the bundles outside of Armbian. If this is a good idea, I'd move it to armbian/kernel-git-shallow in GitHub. And then I'd start using those in armbian-next first as a test ground. I mention I few people I know are interested in the subject @Igor and @going but of course everyone welcome to pitch in Thanks (PS: No idea why I'm required to tag a board for this post)

Hello all, it is this time of the year again. The pcie struggles with certain devices have returned with LK5.10 and are unfortunately not magically gone with LK5.13 As interest around clearfog is not that high, I am not expecting quick solutions here. But will post my findings and perhaps solution. If you have ideas welcome to chime in. pcie especially with wifi cards has been troublesome on clearfog (maybe even linux on the whole) forever(?). In LK5.4 we had it at a point where multiple different ones ran fine. Even "higher performance" ones as QCA988X (WLE600). We also list them as "supported hardware" on the download page... Now starting from LK5.10 they are making problems again. QCA988X is not booting while older one Intel Centrino N2200 works fine. I will try to figure this out... Below are relevant 'dmesg' extracts from the boot. All kernel versions have been booted from the same uboot2018 armbian is using for mvebu/clearfog. Working good LK4.19 Working good LK5.4 Breaking LK5.10 Still broken LK5.13 All bootlogs etc. are also in the armbianmonitor link attached to this post. From a first glance there are some errors assigning the pci memory regions, and the main problem seems to be the power state not changing. I try to figure out breaking version. Greetings, Heisath

Hello, I have discovered interesting behaviour of the clearfogpro switching between lk4.19 and 5.8 and would like to know if others are able to reproduce. And maybe have ideas on how to fix. Steps to reproduce: - have a clearfogpro - get the current armbian image https://archive.armbian.com/clearfogpro/archive/ 20.08 - 'apt update && apt full-upgrade' - set the lan1-6 interfaces to bridging (example via following /etc/network/interfaces : https://pastebin.com/dpXEBe6g ) - reboot - plug into your network should be GBit (on lan1-5). Verify you get ip, and can reach other devices. - run iperf3 between clearfogpro and other gbit device in your network. Should yield about 900MBit/s Now the interesting part: - attach another device to the switch - see how both status leds blink when transfering data via iperf3 ? The bridge seems to run as a hub and not a switch. - now plug a 100mbit/s device into the bridge. - test speed to a gbit device with iperf (both directions): one direction will only yield about 100mbit/s. - while iperf3 is running to the gbit device, unplug and replug the 100mbit/s device on the switch, you should see the rate jump between 100 and 1000..... NOTICE: This only happens in the direction where the clearfogpro is receiving data. Send speed is still at 1gbit/s. Now use armbian-config and switch to LK4.19, reproduce steps from above. You should only see one activity led blinking and the switch functioning correctly at 1gbit/s even with a 100mbit/s device connected. So this leads me to think there's either some difference in the handling of the clearfogpro switch chip (between LK4 and 5) or some difference in bridge package. It would be great if someone could confirm so I am sure, it is not a problem with my setup. root@clearfogpro:~# iperf3 -c 192.168.42.3 -t 100 -R Connecting to host 192.168.42.3, port 5201 Reverse mode, remote host 192.168.42.3 is sending [ 5] local 192.168.42.106 port 33648 connected to 192.168.42.3 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 11.3 MBytes 94.3 Mbits/sec # 100mbit/s device plugged into the switch [ 5] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec [ 5] 4.00-5.00 sec 26.7 MBytes 224 Mbits/sec # 100mbit/s device removed [ 5] 5.00-6.00 sec 107 MBytes 900 Mbits/sec [ 5] 6.00-7.00 sec 105 MBytes 878 Mbits/sec [ 5] 7.00-8.00 sec 107 MBytes 893 Mbits/sec ^C[ 5] 8.00-8.61 sec 63.9 MBytes 885 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-8.61 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-8.61 sec 454 MBytes 443 Mbits/sec receiver

Hi, We made a custom board based on ClearfogBase. And we will change the size of DDR to 512MB. But, I have no idea if it would work without any software changes. Thanks in advance JS

Hi everyone, My name is Gabriel and I am a new person in the community. After installing ARMBIAN (Armbian_5.91_Clearfogbase_Debian_stretch_default_4.14.135) with the Mini PCI Express Marvel 88SE9215, I got a problem with my Clearfog Pro-A1 revision-2.1. It did not work properly like 88SE9215 did not show me my disks. My Idea is to deploy my NAS server with OMV. I tried to compile the kernel so many times with different modules like SATA, PATA, and AHCI but it did not work also. I guess that my u-boot is not setup properly because I was reading a couple post about it and it’s working to everyone. Someone can give me a favor pls and tell me your ideas to try to solve that problem Thanks. Logs: Armbianmonitor: http://ix.io/201C root@clearfogbase:~# lspci 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 0a) 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 0a) 02:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev 11) root@clearfogbase:~# lspci -nv 00:02.0 0604: 11ab:6828 (rev 0a) (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 Capabilities: [100] Advanced Error Reporting 00:03.0 0604: 11ab:6828 (rev 0a) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 00010000-00010fff Memory behind bridge: e0000000-e00fffff Prefetchable memory behind bridge: 00000000-000fffff Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [100] Advanced Error Reporting 02:00.0 0106: 1b4b:9215 (rev 11) (prog-if 01 [AHCI 1.0]) Subsystem: 1b4b:9215 Flags: bus master, fast devsel, latency 0, IRQ 53 I/O ports at 10020 I/O ports at 10030 I/O ports at 10028 I/O ports at 10034 I/O ports at 10000 Memory at e0040000 (32-bit, non-prefetchable) Expansion ROM at e0000000 Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [70] Express Legacy Endpoint, MSI 00 Capabilities: [e0] SATA HBA v0.0 Capabilities: [100] Advanced Error Reporting Kernel driver in use: ahci Booting from Clearfog U-Boot SPL 2018.01-02337-gdc4398fdb8 (May 14 2018 - 19:03:16) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 | -------------------------------- PCIe, Idx 1: detected no link PCIe, Idx 2: detected no link High speed PHY - Ended Successfully DDR3 Training Sequence - Ver TIP-1.29.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR3 Training Sequence - Ended Successfully Trying to boot from SPI U-Boot 2018.01-02337-gdc4398fdb8 (May 14 2018 - 19:03:16 +0200), Build: jenkins-u-boot-clearfog-model=pro,variant=spi-10 SoC: MV88F6828-?? (a) at 1600 MHz DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) MMC: mv_sdh: 0 SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB Model: SolidRun Clearfog Board: SolidRun ClearFog Pro SCSI: SATA link 0 timeout. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Net: eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device ** No partition table - mmc 0 ** starting USB... USB0: Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 ** scanning bus for devices... Found 0 device(s).

Hello, There are many leds on the clearfogpro that I would like to switch off. But /sys/class/leds only has "mmc0::". Is there a way to access other leds ? namely those of the ethernet ports ? Regards deb2016

Hello, I have just updated armbian on my clearfogpro and after the hard drive plugged on the PCIe sata card (2 slots) is no more recognized, it does not appear at all in logs. It was working like a charm before. I wonder what happened ? Here is the output of lspci 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04) 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04) 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter I think the PCIe card is recognized (I have also a wifi card on the other PCI slot). I wonder why armbian does no more see the hard drive, this one is powered I can hear it. It must be due to the u-boot version. Here is the listing of /boot directory : -rw-rw-r-- 1 root root 319 Jan 12 17:28 armbianEnv.txt -rw-rw-r-- 1 root root 319 Jan 12 17:28 armbianEnv.txte -rw-rw-r-- 1 root root 1624 Jan 27 2018 armbian_first_run.txt.template -rw-rw-r-- 1 root root 38518 Jan 27 2018 boot.bmp -rw-rw-r-- 1 root root 1532 Jan 27 2018 boot.cmd -rw-rw-r-- 1 root root 4882 Jan 27 2018 boot-desktop.png -rw-rw-r-- 1 root root 1604 Jan 27 2018 boot.scr -rw-r--r-- 1 root root 123827 Nov 26 08:29 config-4.14.83-mvebu lrwxrwxrwx 1 root root 17 Jan 12 17:21 dtb -> dtb-4.14.83-mvebu drwxr-xr-x 2 root root 4096 Jan 12 17:20 dtb-4.14.83-mvebu lrwxrwxrwx 1 root root 17 Mar 10 2018 dtb.old -> dtb-4.14.18-mvebu -rw-r--r-- 1 root root 5073125 Jan 12 17:21 initrd.img-4.14.83-mvebu -rw-r--r-- 1 root root 2179815 Nov 26 08:29 System.map-4.14.83-mvebu lrwxrwxrwx 1 root root 21 Jan 12 17:21 uInitrd -> uInitrd-4.14.83-mvebu -rw-r--r-- 1 root root 5073189 Jan 12 17:21 uInitrd-4.14.83-mvebu -rwxr-xr-x 1 root root 5450232 Nov 26 08:29 vmlinuz-4.14.83-mvebu lrwxrwxrwx 1 root root 21 Jan 12 17:21 zImage -> vmlinuz-4.14.83-mvebu In the dtb directory, I see many *dtb files, one is for the clearfogpro, but in the logs I can see : [ 0.000000] OF: fdt: Machine model: SolidRun Clearfog A1 Should not it say "Clearfogpro" ?

Good evening, as uboot doesn't get updated automatically since a few versions back, I ran the uboot install script manually today - so far everything worked, uboot got copied to the boot sector. After rebooting though it seems that uboot is not working / properly compiled. It runs normally until the point where it would boot linux, then stops saying it can't find the various commands (bootz, help, echo etc). It dropped me to the uboot shell. I tried a few commands (help, reset etc) and all just gave a "command not found" failure. After restoring the 5.75 uboot from some backup it works again. Is there some known problem in the current uboot? Otherwise we should probably tell users not to upgrade atm. I will provide uboot serial output tomorrow, no time today. Greetings, count-doku

Hi, I have not been able to find clear instructions explaning how to compile u-boot so it detects the installed msata disk. What I think I have to do is rebuild u-boot using the armbian build tools and patch uboot by moving and renaming file below ~/armbian/patch/u-boot/u-boot-mvebu/slot0=sata_1=sata.patch.disabled to the folder ~/armbian/userpatches/u-boot/u-boot-mvebu/board_clearfogpro/slot0=sata_1=sata.patch After builds completes I get a linux-u-boot-clearfogpro_5.74_armhf.deb which I installed and nothing happened the msata disk still not detected. Is that how am I supposted to go about to enable msata support? ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.4.153-mvebu root@armada:~# dpkg -L linux-u-boot-clearfogpro-default /. /usr /usr/lib /usr/lib/linux-u-boot-clearfogpro_5.74_armhf /usr/lib/linux-u-boot-clearfogpro_5.74_armhf/u-boot-uart.flash /usr/lib/linux-u-boot-clearfogpro_5.74_armhf/u-boot-uart.mmc /usr/lib/linux-u-boot-clearfogpro_5.74_armhf/u-boot-uart.sata /usr/lib/linux-u-boot-clearfogpro_5.74_armhf/u-boot.flash /usr/lib/linux-u-boot-clearfogpro_5.74_armhf/u-boot.mmc /usr/lib/linux-u-boot-clearfogpro_5.74_armhf/u-boot.sata /usr/lib/u-boot /usr/lib/u-boot/LICENSE /usr/lib/u-boot/platform_install.sh

Hi, does anyone know if the provided UART interface on the mikrobus header on the clearfog is 5V tolerant? Greetings, count-doku

EDIT: This started off as a request for help starting up a 4G modem. After attempting to connect ANY network with nmtui, it's become also a request to configure a terminal such as 'screen' to be able to see the nmtui commands for any connection. I recently acquired an U-Blox MPCI-L201 4g LTE modem. This is my first time attempting this type of connection and things are not as intuitive as I would hope so I thought I would reach out. I downloaded the most recent Armbian Stretch from the downloads page and re-flashed the emmc. lsusb clearly shows the device root@clearfogpro:~# lsusb Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 1546:1146 U-Blox AG Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@clearfogpro:~# I'm using screen in a command box on an XU4 with Hardkernel's 18.04 as the host. I've had good results with nmtui on a fresh Armbian install to set up the initial network connection, so I thought I would give that a try. It looks like the modem shows 4 additional wired connections that are not there if the card is removed. But I have to move the cursor to get something to display - If I move the cursor up and down it exposes the entries - Choosing Activate reveals the four wired connections - so it appears the hardware is 'working.' These entries only show if the device is in either of the mpci slots. But it gets more difficult to decipher from there. Attempting to select one of the wired connections and then the Activate button makes it impossible to figure out what's happening on the screen - Armbian-config displays similarly so I'm assuming this particular problem is graphic oriented. I booted the XU4 into an Armbian build and had similar results. I found some really detailed information on the screen command that, while really interesting, was basically useless for this issue as far as I can tell as I couldn't find any formatting parameters with the exception of the "-a" switch which I think should automatically try to format pages but it didn't make a difference. Through trial and success I connected to my Hotspot so I updated and upgraded, but that made no difference. But now I can find its ip and connect via ssh, and nmtui is nice via ssh! But armbian-config, although it appears to run properly, complains that it does not have internet although clearly it does - As I tried several times I noted the asterisks (*) move to different wired connections under USB Ethernet. After connecting via SSH I noted the <Activate> button becomes <Deactivate> when highlighting a starred entry, verified with my WiFi hotspot. (BUT how is the Eth1 active with nothing connected?) So this leads me to ask a couple questions ... a) How to get past this 'screen' issue. In the past I've noticed these graphic issues don't happen on an SSH session. I was lucky to guess and type the passphrase of my wifi and get this connected. I tried unsuccessfully several times to guess and enter the info for one of the ethernet ports. I tried several different terminal emulators, all had weird display results. I really need to be controlling the device through the USB serial rather than ssh through a hotspot on my phone. Again, it was a good guess getting this connected and I don't want to try again to get onto my local wifi. b) once I was able to SSH to the clearfog, armbian-config shows me there is an ethernet connection over USB0 along side the terminal connection - how can I connect to this? I know there is a way to have multiple IPs on an adapter in linux but I haven't tried that; the instructions I found seemed more complex than I wanted to dive into, although I'd bet there's a simple proper way to do this. c) What's the proper, or a better, way to enable a new 4G modem? I read some cryptic notes about wvdial on a TV box and followed some google links to various docs but I'm not quite putting it together. (separate post) Or is it even an issue as it looks like it and the sim work together to "just connect?" d) If it is connected, or when I get it connected, how to I determine what the details are such as its IP, etc? It appears that it 'just works' but I need to be able to reference it for networking and, well, learn something. Thanks in advance for any advice offered.

Hi, I updated my ClearfogPro today and noticed (that like in the last updates), updating the linux-u-boot-clearfogpro-next package fails, with the error "/dev/mmcblk2" doesn't exist". This happen obviously, because I don't have a SD Card installed, as I am using a M.2 SSD to boot and as root. Quick check inside the .deb file revealed the platform_install.sh which only tries writing the u-boot.mmc version to /dev/mmcblk2. For me this is not a big problem, I know how to get the correct u-boot into place (/usr/lib/linux-u-boot-next-clearfogpro_5.60_armhf/u-boot.sata) but new users might find it difficult. Would it be possible to let the users select the device for writing the u-boot when the mmc variant fails? Just a popup with a text saying: "Could not write u-boot to default location (sdcard/mmc), please specify device" and a textbox below... (Might even look into doing something like this myself and then send a PR) Or does Armbian normally keep track of where the u-boot is and I just did something wrong when moving from sdcard to ssd? Greetings, count-doku EDIT: Just realised this might apply to other boards to, if it would better fit into Development or so, please move.

Hello everyone, I am trying to achieve first boot with a Clearfog Base with eMMC. It was not clear (at least to me) that the eMMC version does not allow booting from SD card *at all* But hey, let's get this baby up&running, can anybody please help me? I am trying to follow this procedure [https://www.armbian.com/clearfog-base/]: 1) Write the image to a USB flash drive -> easy enough, I did it with Win32DiskImager and a well-tested 64GB USB stick 2) Load the modified u-boot (from the Armbian image) using the UART method -> I have issues here. I suppose that UART method consists in plugging in the microUSB cable into my PC and open the COM3 port with Putty, than hitting some key to interrupt normal boot. Unfortunately the terminal just spits out garbled text. The setup for the COM3 port in windows is 9600bps, 8data, no parity, 1 stop, no flow control and matches the config in Putty. Where do I find the modified u-boot in armbian image? I'm stuck here, and I don't know how to proceed. Thank you Genesio

In the download section under Clearfog Pro Tested Hardware it shows a European version of the ME909S mpcie LTE adapter and a link to the German Amazon product page. I just want to confirm the US equivalent is compatible - https://www.amazon.com/HUAWEI-ME909S-821-Wireless-DC-HSPA-TD-SCDMA/dp/B01CCFS0SY/ref=sr_1_2?s=electronics&amp;ie=UTF8&amp;qid=1532795467&amp;sr=1-2&amp;keywords=ME909s Thanks in advance

Hello, I have recently bought one clearfogpro and one orangepi+ 2e. I power them with a RD65A adapter which delivers both 5V and 12V DC. You can see everything on the pictures. There is also a 2.5" hard drive connected to the clearfogpro. Before powering up everything, I would like to be sure all cables are correctly connected, there is the picture of all connections to the RD65A 1) The main power cable : the red (phase) goes to the L, the blue (neutral) goes to the N, and the green/yellow goes to the ground. 2) V1 is 5V for RD65A, so I plugged the orangepi+ 2e and red cable of the sata power 3) V2 is 12V for RD65A, so I plugged the clearfogpro on it, there is also the yellow cable of the sata power, but not sure it is needed as it is a 2.5" hard drive, I assume all black cables are to be connected to the ground or negative : which should be COM on the RD65A, then all red cables should go on the positive entry (+V1 or +V2). The power of the 4D65A is 66W, I think it is enough for all device connected, even at boot when all devices requires the maximum of power. Let me know if there is something to correct or improve. Regards deb2016

Hello, I installed the latest armbian mainline image on my clearfog pro. I plugged a wifi card on it. I would like to set up the armbian network so as to use it as a gateway towards the ISP box. Concretely, here the scheme : internet <---- ADSL-----> ISP box <------- RJ45 ----------> clearfog <-------- wifi --------> PC1, tablet, ... <------- RJ45 -------> PC2, printer, ... Currently I use this scheme with an old router (linksys/dd-wrt) which is configured as a gateway : - all dhcp request are forwarded to the ISP box - there is only one network 192.168.1.0/24 : the ISP box is 192.168.1.1 (local) and assigns all other devices (connected indirectly by the router) an IP like 192.168.1.XXX I would like to do the same with clearfog, but could not find any relevant guide or tutorial to do so, after days googling. Yet, there are some useful posts on this forum, but not enough detailing the way they do. Could anyone detail me what I would need to do ? Do i need to set up a bridge ? Thanks for your kind help Regards

Hello, I have a small fan (2-3cm diameter). Do you know if it is possible to plug it on the clearfogpro board ? On the mikrobus header, one can see GND, 5V, 3.3V slots. Can I plug the fan wires into these ? Thanks for your attention Regards

Hi, out of interest I was checking the I²C Devices connected to the ClearfogPro. So this is thought as a small guide to the i2c bus. The second i2c bus goes straight to the mikrobus/click header so there is nothing on default. --- i2cdetect for bus 0 gave me: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Device 0x20 ) After checking the device tree and schematics, the device at 0x20 is the IO Expander used by a driver. Device 0x4c ) The 0x4c device is also listed in the dt. As the AD Converter for mikrobus/click header. I confirmed this working. You can use this, to read the current value. i2cget 0 0x4c 0x99 w 0x4c is the bus address. 0x99 is the data address according to the MCP3021 datasheet, w means we want to get a word. It then returns the current value, which can be interpreted by using the formula from the datasheet. Device 0x64 ) I don't know what is on the bus here. Neither the datasheet nor the device tree mentions anything, does anyone know? --- I2C Flash 24AA025UID ) The datasheet mentions the flash chip is only assembled in DNP assembly (checked not on my board) so this device is not available. I hope this helps someone else understand how to use the analog input pin and maybe give me a hint whats at 0x64. Greetings, count-doku

Hi, I am currently using the back side push button on my clearfog pro for bringing the device to poweroff / halt. The easiest way to configure it like that seemed to change the button_0 entry in the device tree From: button_0 { label = "Rear Button"; gpios = <0x23 0x2 0x1>; linux,can-disable; linux,code = <0x100>; }; To: button_0 { label = "Rear Button"; gpios = <0x23 0x2 0x1>; linux,can-disable; linux,code = <0x74>; }; The linux code 0x74 signals the device to perform a graceful shutdown. Unfortunately I have to readjust the device tree after every update. I wouldn't suggest to change it to 0x74 for everyone, but would a config switch or a device tree overlay be possible for that? I prepared this, but am unsure how to compile / integrate it. // Switch back button event id /dts-v1/; /plugin/; / { compatible = "solidrun,clearfog-a1", "marvell,armada388", "marvell,armada385", "marvell,armada380"; fragment@0 { target = <&button_0>; __overlay__ { linux,code = <0x74>; }; }; }; Greetings, count-doku

Hi, quick question, is the Bug/Limitation listed in the docs (https://docs.armbian.com/Hardware_Marvell/#bugs-or-limitation_1) regarding using sfp with mainline kernel still there? Or was it fixed in the meantime? I am thinking about ordering a sfp module but want to make sure it is supported first. Greetings, count-doku

EDIT: only the card in what I'm calling slot two is detected by lspci. wifi card near SoM - at boot PCI-e 0: Detected No Link. PCI-e 2 (IF 1 - bus 0) Root Complex Interface, Detected Link X1, GEN 1.1 ... once booted root@clearfogpro:~# lspci 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04) wifi card in slot nearer edge of board - at boot PCI-e 1 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 1.1 PCI-e 1: Detected No Link. ... once booted 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04) 01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter This wifi card - https://www.amazon.com/gp/product/B011SI4544/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1 Here is the full log of both boots Kind of funny as I didn't think of trying the other slot because I 'wanted' to put it in the middle of the board for simplicity of running the antenna wires ... I'll figure out a new antenna layout, glad the thing gets seen in Armbian! I removed network-manager from 5.38 stretch next 4.14.14 so I have to do this manually. Not finding the card was kind of breathtaking as it was suggested to use this chipset. Thought I might pass this on if anyone else is having detection problems. EDIT: only slot 2 gets identified with lspci I know I've read somewhere something about 'serdes' as you will see in the u-boot messages but I just can't figure out what I'm looking for. I also have a 4 port Marvell SATA card that will only detect in the 2nd PCI-e slot. (mPCI-e?) Anyway, only the card in the slot farthest from the SoM gets reported by lspci but they both show when u-boot detects them. I have no clue where to look for this answer - any pointers? Here is the full boot output with my SATA card in slot 0 and the wifi card in slot 2 I can't give armbianmonitor -u as I don't have any networking set up yet.

Background Most of the instructions I found on installing anything on the Clearfog Pro or Base with eMMC were either not applicable to me, incomplete or missing some file or there was some other barrier. After a couple weeks of tinkering and notation I feel I have a good handle on getting Armbian on this board by several different methods. Here I will describe my path to using TFTP to install Armbian on my Clearfog Pro. First off, I have no clue why so many tutorials include a line that reads something like "but that would require you to set up a TFTP server so we're going to go through a lot of other rigamarole instead.' Really? This guide got my TFTP server up and running in a few minutes, all I had to figure out was that since I had used sudo to install the server, it owned the tftpboot directory so copying files there took root or sudo to do it, which is fine since you probably want a little security over a TFTP directory anyway. I have an M.2 SSD drive installed on my Clearfog, but these instructions should work if you use a USB stick large enough to carry the images. If the Clearfog had a little more RAM, we could do it all on the hardware but Armbian images are too large to fit in RAM with Buildroot or U-Boot so we need an intermediate medium. In another post I'll describe doing the entire install from a prepared M.2 SSD. I chose the TFTP path for my first load because the U-Boot that ships with the board is configured to attempt to find files via TFTP if it fails to find what it is looking for locally. At the time I had no clue what I was about to learn about the U-Boot process or all the configuration it goes through. I just knew it was looking for boot.scr via tftp so I decided to give it what it was looking for. Further investigation revealed that the U-boot that ships with the board is 'broken' in that it doesn't allow the obvious function of booting from USB and can't interact with the USB storage. The buildroot image that can load to ram via TFTP can interact with 'SCSI' and USB storage, so again I felt TFTP was the way to go. The instructions on this page have necessary files and info to get their version of Debian on it but it is missing a CRITICAL instruction in section 8 to boot the board. It took me days to figure that out, after mostly realizing how similar the various boot methods are. If you are interested in following those instructions see this post I made on the Solid Run forum and add that line to the end of section 8. This forum post has very good information on the U-boot part of the process. This information helped me immensely. If you use the 'next' kernel (as of 4.14.14) you will have to remove network manager and configure networking manually. 'Default' (4.4.112 currently) networking is fine. I am using Armbian_5.38_Clearfogpro_Debian_stretch_next_4.4.112.img in this guide. The step by step This guide is verbose - it assumes little. I hope to have made this so even someone fairly new to SBCs should be able to get this board up and running a basic Armbian configuration. Get the necessary files Download u-boot.mmc from Solidruns download page for Clearfog Download clearfog-emmc.tar.gz and extract zImage armada-388-clearfog.dtb boot.scr from the link in the emmc section on Solidruns installation page Download an Armbian image of your choice from Armbian's Clearfog download page, I used the 'default' image for now because I don't want to go through configuring networking manually Armbian_5.38_Clearfogpro_Debian_stretch_next_4.4.112.img Prepare your TFTP server install your favorite TFTP server or follow the instructions on the link above and move the following files to your tftp boot directory (I had to use su to move the files) - u-boot.mmc zImage armada-388-clearfog.dtb boot.scr Armbian_5.38_Clearfogpro_Debian_stretch_next_4.4.112.img Connect to the Clearfog terminal You will need a USB terminal program on your host PC. I use an Odroid XU4 with Armbian. 'screen' is the terminal I like, use any you want. For me, opening any terminal and typing screen /dev/ttyUSB0 115200 gets me a display ready for the Clearfog. (connect a USB to micro USB cable to the Clearfog and your PC ...) Make sure the dip switches are configured for eMMC boot. Power up the Clearfog and you should see U-boot load and attempt to find bootfiles. It was a scary screen of failures the first time I saw it, don't worry we're going to get that looking the way we want. Configure the stock U-Boot to see the TFTP server Since you probably let it go past the stop boot prompt, power down the Clearfog and power it up again ;] stop the boot process by pressing a key when instructed. You will get a Marvell>> prompt. We need to set some IP parameters so U-boot can find the TFTP server - setenv serverip [IP of your TFTP server] setenv ipaddr [IP that you want the Clearfog to have] Write the newer U-Boot to eMMC Now we can attempt to write the eMMC u-boot image to eMMC by TFTP. We have to bring it down from the TFTP server to ram, then write the file from ram to the eMMC - tftpboot 0x02000000 u-boot.mmc mmc write 0x02000000 0 ${filesize} Now we want the new u-boot to load, so we have to reboot the board from the currently running u-boot reset You should notice a difference with the boot behavior with the new U-boot. Again, we stop the boot process when prompted. Of course you will be tempted to let it run through its failures, the messages are very educational. To continue, stop the boot process. Boot to Buildroot Now we need a little more functionality than U-Boot can give us. We can do some of these in U-Boot but it is much easier and IMO better in a basic linux environment. Buildroot is good for this and Solidrun has provided a buildroot image that provides access to the USB and M.2 storage. From the Marvell>> prompt - tftp 0x2000000 zImage tftp 0x1000000 armada-388-clearfog.dtb You will see the data load, the zImage is larger and takes just a second, the dtb file is almost instant. Once these are loaded into memory storage we need to start the image we loaded into the first address and pass it the device tree data we loaded into the second address - bootz 0x2000000 - 0x1000000 You should now have a Buildroot prompt. Login with root, it will not ask for a password. Kewl! You now have basic linux hardware control at this point. Configure IP We need to set our IP address so we can bring down the Armbian image via TFTP. ifconfig eth0 [IP address of your Clearfog] netmask [your networks mask] up Prepare your SSD drive I created the filesystem on the Clearfog so there was no incompatibility superstition on my part ... obviously only do this once. You could do it on a host PC, but again I didn't want to have to mess with any kind of permission issue or controller incompatibility, etc. Confirm your SSD device - fdisk -l I'm assuming your device is at /dev/sda. If there is a partition on the SSD delete it - fdisk /dev/sda d (once for each partition if multiple exist) w Now we know we have a 'clean' drive but need to go ahead and partition it - fdisk /dev/sda o (create the partition table) n (new partition) p (primary) 1 (first partition) 257 (just start it at 257 ... I failed to note where I found this and why) (enter to accept default, last sector) w (write to the drive) There is a lot of instructions online for the linux fdisk command. While this guide assumes little, it is beyond my scope to teach fdisk and mkfs. Take a look here and here. If you type exactly as above (excluding parenthesis data) it should create a partition and leave enough in the front for u-boot and the file allocation table. Now we need to create a filesystem. I want to use ext4 64 bit so the mkfs command ends up being - mkfs.ext4 -O ^64bit /dev/sda1 We can now mount the drive mkdir /ssd mount /dev/sda1 /ssd cd /ssd and bring down the image via TFTP tftp -g -r Armbian_5.38_Clearfogpro_Debian_stretch_next_4.4.112.img [TFTP server IP] Just for the thoroughness of it I brought all the files in the TFTP directory to my SSD ... Write the image to eMMC Now we can actually put the image in the Clearfog eMMC - dd if=Armbian_5.38_Clearfogpro_Debian_stretch_next_4.14.14.img bs=1M of=/dev/mmcblk0 The eMMC will always be mmcblk0 and will have mmcblk0p1 after the image is written. We can't mount this partition yet, so lets reboot and get one step closer. reboot Prepare the Armbian U-Boot The new image has overwritten all the U-Boot parameters, so we'll have to tell U-Boot the network information again.Stop the boot process again and at the Marvell>> prompt setenv serverip [your TFTP server IP] setenv ipaddr {your Clearfog IP] saveenv reset Load boot.scr via TFTP and start Armbian Now when it boots it will fail to load the boot.scr from the mmc because we still have to put it there, so we will let the boot.scr load via tftp. U-Boot tries numerous ways to boot before it gets to trying boot.scr via TFTP. We will have to ctrl-c several times to stop the failing attempts until it finally finds the script on the tftp server, then it will start to boot Armbian. Alternatively we could just sit and wait a very long time for each operation to time out but I've not once had the patience to do that! Once U-Boot finds boot.scr on the TFTP server it should load Armbian from eMMC. Armbian will force you to do the first login process where you will replace your root password and create a user. Finalize Armbian so it loads boot.scr from eMMC Now we can copy the boot script to the root of the mmc. Log in as root with your new password then - mkdir /ssd mount /dev/sda1 /ssd mkdir /emmc mount /dev/mmcblk0p1 /emmc cp /ssd/boot/boot.scr /emmc/boot.scr reboot This time don't interrupt the boot process, the unit should boot from mmc. OMG you're freakin' done! Play with Armbian. ***PLEASE respond with corrections, clarifications and additions and I will update this post.

Hi, this is not really a problem but a thing I stumbled upon a few weeks ago, when compiling armbian myself. For reasons unknown to me, when I check the pcie support option in the kernel settings, the ath10k pci driver (as used for wle600vx for example) cannot be loaded anymore. The armbian tries to load various firmware files, always falling back till the last one. Then booting continues w/o ath10k so no wifi.... I never got around the function of the pcie feature anyway, both mpcie slots are fully operational with only pci enabled in the kernel config. Did I misunderstand this menu option? Greetings, count-doku