count-doku

Members
  • Content Count

    42
  • Joined

  • Last visited

About count-doku

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. count-doku

    Helios4 Support

    One other thing to check if the disks are faulty / just doing the clicking -> connect them to some computer. Listen there.
  2. just to answer your original question mdm63, as nobody else seems to be able to give some simple answer without talking about money. As Armbian is hosted on github you will probably always be able to build images for your board even if it is EOS/EOL. Worst case is that you will have to go back and pick some commit in which the board is still available in the build script ( if they at somepoint remove the configs for the board). I would suggest that you make some backup of the current (or last working) version of the buildscript (and maybe cache / kernel) so that even if the repositiory is gone, you can still generate images for your board. Greetings, count-doku
  3. Hi there, I realized that in the documentation for Marvell Mainline SFP is listed as unsupported. ( https://docs.armbian.com/Hardware_Marvell/#mainline ) So I tested that with some SFP Module I had laying around (SFP -> 1Gbit/s TP, no fiber though), and everything seems to be working fine. I will attach armbianmonitor -u and some proof. Maybe you can then put SFP as supported for mainline armada. Armbianmonitor -u: http://ix.io/1APB Used module: https://www.ebay.de/itm/142747822671 (maybe this can also be added as tested to the download page) ethtool output with attached sfp module (and cable): root@clearfogpro:~# ethtool eth2 Settings for eth2: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 22 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Link detected: yes Iperf3 Test from Windows Machine, notice big difference in sending / receiving. PS D:\Data\Desktop\iperf-3.1.3-win64> .\iperf3.exe -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [ 4] local 192.168.1.170 port 50522 connected to 192.168.1.1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 104 MBytes 870 Mbits/sec [ 4] 1.00-2.00 sec 107 MBytes 895 Mbits/sec [ 4] 2.00-3.00 sec 109 MBytes 916 Mbits/sec [ 4] 3.00-4.00 sec 109 MBytes 917 Mbits/sec [ 4] 4.00-5.00 sec 108 MBytes 910 Mbits/sec [ 4] 5.00-6.00 sec 109 MBytes 915 Mbits/sec [ 4] 6.00-7.00 sec 109 MBytes 913 Mbits/sec [ 4] 7.00-8.00 sec 108 MBytes 910 Mbits/sec [ 4] 8.00-9.00 sec 108 MBytes 906 Mbits/sec [ 4] 9.00-10.00 sec 109 MBytes 911 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.06 GBytes 906 Mbits/sec sender [ 4] 0.00-10.00 sec 1.06 GBytes 906 Mbits/sec receiver iperf Done. PS D:\Data\Desktop\iperf-3.1.3-win64> .\iperf3.exe -Rc 192.168.1.1 Connecting to host 192.168.1.1, port 5201 Reverse mode, remote host 192.168.1.1 is sending [ 4] local 192.168.1.170 port 50524 connected to 192.168.1.1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 63.9 MBytes 534 Mbits/sec [ 4] 1.00-2.00 sec 62.3 MBytes 524 Mbits/sec [ 4] 2.00-3.00 sec 71.0 MBytes 596 Mbits/sec [ 4] 3.00-4.00 sec 72.0 MBytes 604 Mbits/sec [ 4] 4.00-5.00 sec 71.5 MBytes 600 Mbits/sec [ 4] 5.00-6.00 sec 71.3 MBytes 598 Mbits/sec [ 4] 6.00-7.00 sec 68.8 MBytes 577 Mbits/sec [ 4] 7.00-8.00 sec 69.8 MBytes 585 Mbits/sec [ 4] 8.00-9.00 sec 70.3 MBytes 589 Mbits/sec [ 4] 9.00-10.00 sec 65.7 MBytes 551 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 687 MBytes 576 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 687 MBytes 576 Mbits/sec receiver iperf Done. PS D:\Data\Desktop\iperf-3.1.3-win64> Greetings, count-doku
  4. Did you try going back to the old armbian version? You could use git to checkout some old commit and build your own image from there. But Igor can possibly describe this better. Might also take the old 5.59 Version from the archive: https://dl.armbian.com/clearfogpro/archive/ Armbian_5.59_Clearfogpro_Debian_stretch_next_4.14.66.7z from 22.08.2018 If everything is working again when using 5.59 we could go from there and check what changed (if anything). If it is not working in the old version I'd say some of your hardware is broken. Maybe try to return / exchange the clearfogpro.
  5. Hey, which SATA and WiFi Cards are you using exactly? What driver are you using for the wifi card (if it needed to be installed additionally?) I remember that I had a similiar issue, a while back, which was caused by the wifi card... After trying a different one it was solved. Maybe just some combination of cards does not work. Btw. your uboot seems to correctly detect the link: Will try later with mine (currently only one inserted) and edit this post with the results. EDIT: I am using a Qualcomm Atheros Wifi Card, the Compex WLE600VX http://www.compex.com.sg/product/wle600vx/ (inserted in the slot next to the som / cpu) and a cheap Delock 95233 mPCIe to SATA adapter https://www.delock.com/produkte/G_95233/merkmale.html Running current armbian next for clearfogpro. (fresh update, also updated uboot) Both are working fine - and the uboot detections looks very similiar to yours. Most interesting in the beginning, where it first prints "PCIe, Idx 2: detected no link" followed by "PCI-e 2 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1" a few lines later. This looks exactly the same as in your boot up. I attached the uboot, linux boot up and lspci output. Greetings, count-doku
  6. count-doku

    Clearfog[Pro]mikroBus UART 5V tolerant

    Ok thanks for the info. Was just wondering, because on the mikroBus Header there's also a 5V out. But in the meantime I also measured the voltage on the tx pin of the clearfog and that's at max 3.3V due to pullup resistors. So 3.3V seems like a safe choice. Greetings!
  7. Hi, does anyone know if the provided UART interface on the mikrobus header on the clearfog is 5V tolerant? Greetings, count-doku
  8. count-doku

    read first How to build my own image or kernel?

    I used this as a patch. That enables building of the pcm5102a module. Put it in userpatches/kernel/yourkernel I got the feeling that Kconfig just doesnt show entries without a text in menuconfig. diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index c367d110..87c6ae4c 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -680,7 +680,7 @@ config SND_SOC_PCM3168A_SPI select REGMAP_SPI config SND_SOC_PCM5102A - tristate + tristate "Texas Instruments PCM5102A CODEC - I2S" config SND_SOC_PCM512x tristate
  9. count-doku

    testers wanted Testers wanted: sunxi Device Tree overlays

    Yes I am sure that the I2S0 port is enabled, Armbian provides a overlay for that (https://github.com/armbian/build/blob/18215550b367919c1b270185e110b901e2843edd/patch/kernel/sunxi-next/add-sunxi-overlays.patch#L2246-L2276) Which I enabled via Armbian-Config / armbianEnv.txt... Also checked that the device is there using /proc/device-tree/ That is also the reason why I didn't keep the I2S -> Okay Lines from the Raspberry PI overlay. That the driver is normally not included is correct, I will add it and then build my own image. But first I would love to get the device tree overlay working. I will conduct some more testing this afternoon or tomorrow and update this reply with my results. EDIT: So I've got the nodes integrated in the device tree, but not using overlays but decompiling and recompiling it online with dtc. I added the following nodes, maybe someone can create a overlay from that? // under soc sound:sound { compatible="hifiberry,hifiberry-dac"; i2s-controller=<0x99>; // this is taken from above i2s controller, in the overlay there should be a label I guess status="okay"; }; // in the root pcm5102a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; status="okay"; }; Testing in /proc revealed the changes had been loaded correctly. Then I tried compiling my own kernel with the PCM5102A driver but the option is not displayed in the kernel configuration. Any ideas? Greetings, count-doku
  10. count-doku

    testers wanted Testers wanted: sunxi Device Tree overlays

    Hi, I have the Banana Pi M1 and the Banana Pro and just received a I2S to Analogue Module. I'd love to use these together but unfortunately there is no device tree overlay available. The module is from Adafruit (https://learn.adafruit.com/adafruit-i2s-stereo-decoder-uda1334a) they also mention it is the same chip / driver that is also used by the Hifiberry DAC, there is support for Raspbian also with an overlay etc. (see the Raspberry PI kernel tree | https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/hifiberry-dac-overlay.dts). I tried adapting the overlay for usage with the Banana but didn't get it running. So any help would be greatly appreciated, I will then of course test and report. Also have a uart to usb cable to access uboot and can build images. This is what I have so far: /dts-v1/; /plugin/; / { compatible = "allwinner,sun7i-a20"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; status = "okay"; }; }; }; fragment@1 { target = "/soc@01c00000"; __overlay__ { sound: sound { compatible = "hifiberry,hifiberry-dac"; i2s-controller = <&i2s0>; status = "okay"; }; }; }; }; Of course using above overlay and enabled I2S0 Port already with Armbian-Config / armbianEnv.txt and the provided overlay. Naturally there is a driver / codec required to get the Sound Module working, but I think we could use the driver from the Raspbian Kernel Source: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/sound/soc/codecs/pcm5102a.c Doesn't seem to rely on anything raspberry specific. I would integrate, test and the do a PR on github, with this stuff, but need some help getting the overlay working first. Greetings, Count-Doku
  11. As there were no answers I suspect most people run of the sdcard / mmc anyways, or manually moving u-boot into place after an update does not bother them. So I wrote a small update code for myself (see below), feel free to use it. #!/bin/bash DIR=/usr/lib/linux-u-boot-next-clearfogpro_5.60_armhf VARIANT=u-boot.mmc DEVICE=/dev/mmcblk2 if [ -b $DEVICE ]; then echo "Writing u-boot to default location..." dd if=$DIR/$VARIANT of=$DEVICE bs=512 seek=1 status=noxfer echo "Completed!" exit 1; else echo 'Could not write the default uboot to mmc/sdcard ' read -p 'Please enter uboot variant to install: mmc, sd, sata, flash > ' VARIANT case $VARIANT in mmc|MMC|sd|SD) VARIANT=u-boot.mmc ;; sata|SATA) VARIANT=u-boot.sata ;; flash|FLASH) VARIANT=u-boot.flash ;; *) echo 'Invalid variant, aborting.' exit 0 ;; esac read -p 'Enter boot device (eg. /dev/mmcblk2) > ' DEVICE if [ ! -b $DEVICE ]; then echo "Device not available, aborting!" exit 0; fi echo '' echo 'U-Boot Path: ' $DIR echo 'Will now try to write ' $VARIANT ' to ' $DEVICE read -p 'Start writing? (yes/no)' START if [ $START == "yes" ]; then echo "Writing..." dd if=$DIR/$VARIANT of=$DEVICE bs=512 seek=1 status=noxfer echo "Completed!" exit 1 fi fi Of course things like the U-Boot Directory change and need to be adjusted. It could also be called as a parameter. I am unsure if it is possible to integrate that into Armbian as I could not find out, where the related linux-u-boot-clearfogpro-next.deb Packages gets build / comes from. Greetings, count-doku
  12. 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.
  13. count-doku

    clearfogpro plug fan

    Yes you could use the Pins from the mikrobus header but make sure your fan does not draw to much power for the 5V regulator. If it is a 12V fan you could also run it directly on your input (if this is 12V). There are some headers near the power plug which can be used with a small adapter. I attached an image which highlights the connectors. Check https://wiki.solid-run.com/lib/exe/fetch.php?media=a38x:carrierboard:docs:clearfog-schematics-2.1.pdf for the schematics. The power regulators etc are on page 13... EDIT: looks like the power regulator for 5V is the RT2875A/B which can source up to 3A. Greetings
  14. count-doku

    Clearfog pro network : make a gateway

    Answer to question 1: Yes eth0 goes to the isp box. And br0 to my network. But I forward my global ipv4 from the isp box directly so they are not the same network. Internet ---- ISP Box (Modem) ------ Clearfog -------- br0 ------ lan1-6 77.11.22.33 192.168.1.1 \-- wlan So the clearfog is directly connected with the internet and the isp box is a completely transparent ethernet / dsl bridge. --- Answer to second question: yes they are configured manually. The auto stanza only means the interfaces get ifup'ed automatically. The actual lan ports (1-6) don't get IPs themselves. They only got MAC Addresses (like a switch). Only the br0 interfaces has a local ip (192.168.1.1). Then all packets from lan1-6 go over the br0 interface. All the routing etc. is based on that. Greetings
  15. Ok then I wont worry about my temps. Stable at 45°C. Thanks.