Skip to content

Intel I350 T4V2

Hardware
  • Es gab welche im Pine64-Forum, die schrieben das diese Karte auf dem ROCKPro64 läuft. Ok, da ich an so einer Karte sehr interessiert bin, mal eben bestellt und eingebaut.

    0_1534361077398_Intel_I350_T4V2_ergebnis.jpg

    Ich bekomme sie leider nicht zum Laufen 😞

    Software

    rock64@rockpro64:~$ uname -a
    Linux rockpro64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 GNU/Linux
    

    Treiber

    https://downloadcenter.intel.com/download/13663

    Modul

    Modul gebaut nach Anleitung

    rock64@rockpro64:~$ lsmod
    Module                  Size  Used by
    midgard_kbase         651264  0
    dw_hdmi_i2s_audio      16384  0
    rockchip_saradc        16384  0
    igb                   196608  0
    ip_tables              24576  0
    x_tables               32768  1 ip_tables
    autofs4                40960  0
    phy_rockchip_pcie      16384  0
    

    Wird dann wohl geladen. In /etc/modules eingetragen, damit es beim Start geladen wird.

    Problem

    Wenn ich das Modul entlade und erneut lade, bekomme ich diese Meldung mit dmesg

    [ 1047.587217] Intel(R) Gigabit Ethernet Linux Driver - version 5.3.5.18
    [ 1047.587897] Copyright(c) 2007 - 2018 Intel Corporation.
    

    Das kann nicht alles sein, weil danach die Schnittstellen gesetzt werden müssten.

    Da die Hardware auch nicht wirklich aussieht, als wenn sie lebt. Keine LED leuchtet wenn ich ein Kabel einstecke, kann da was nicht richtig sein. Das Kommando

    sudo lspci -vvv
    

    spuckt auch gar nichts aus. Also scheint die Karte nicht zu funktionieren.

    root@rockpro64:/home/rock64# dmesg | grep -E pcie                
    [    0.504076] of_get_named_gpiod_flags: parsed 'gpio' property of node '/vcc3v3-pcie-regulator[0]' - status (0)
    [    0.504126] reg-fixed-voltage vcc3v3-pcie-regulator: Looking up vin-supply from device tree
    [    0.504165] vcc3v3_pcie: supplied by dc_12v
    [    0.504230] vcc3v3_pcie: 3300 mV 
    [    0.504383] reg-fixed-voltage vcc3v3-pcie-regulator: vcc3v3_pcie supplying 3300000uV
    [    2.040888] vcc3v3_pcie: disabling
    [    2.311600] phy phy-pcie-phy.9: Looking up phy-supply from device tree
    [    2.311617] phy phy-pcie-phy.9: Looking up phy-supply property in node /pcie-phy failed
    [    2.313550] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep
    [    2.313567] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup
    [    2.313613] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0)
    [    2.314014] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree
    [    2.314148] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree
    [    2.314164] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed
    [    2.314200] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
    [    2.318356] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree
    [    2.318372] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed
    [    2.318399] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found
    [    2.323371] rockchip-pcie f8000000.pcie: invalid power supply
    [    2.827428] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
    [    2.827625] rockchip-pcie: probe of f8000000.pcie failed with error -110
    root@rockpro64:/home/rock64# 
    

    Zum Vergleich, erfolgreiche Initialisierung der NVMe PCIe Karte.

    rock64@rockpro64v2_0:/sys/class/hwmon/hwmon0$ dmesg | grep -E pcie
    [    0.503626] of_get_named_gpiod_flags: parsed 'gpio' property of node '/vcc3v3-pcie-regulator[0]' - status (0)
    [    0.503677] reg-fixed-voltage vcc3v3-pcie-regulator: Looking up vin-supply from device tree
    [    0.503716] vcc3v3_pcie: supplied by dc_12v
    [    0.503781] vcc3v3_pcie: 3300 mV 
    [    0.503932] reg-fixed-voltage vcc3v3-pcie-regulator: vcc3v3_pcie supplying 3300000uV
    [    2.654296] vcc3v3_pcie: disabling
    [    3.143787] phy phy-pcie-phy.9: Looking up phy-supply from device tree
    [    3.143792] phy phy-pcie-phy.9: Looking up phy-supply property in node /pcie-phy failed
    [    3.190780] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep
    [    3.190793] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup
    [    3.190867] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0)
    [    3.191154] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree
    [    3.191314] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree
    [    3.191323] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed
    [    3.191353] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
    [    3.197618] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree
    [    3.197634] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed
    [    3.197660] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found
    [    3.202254] rockchip-pcie f8000000.pcie: invalid power supply
    [    3.262707] PCI host bridge /pcie@f8000000 ranges:
    [    3.280803] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
    [    3.339349] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
    [    3.350365] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
    [    3.365292] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
    [    3.368352] aer 0000:00:00.0:pcie02: service driver aer loaded
    

    Und noch eine merkwürdige Meldung, die ich aber nach Recherche vergessen kann. Soll den Kernel wohl nur als modifiziert flaggen.

    root@rockpro64:/home/rock64# dmesg | grep -E  igb
    [    3.511084] igb: loading out-of-tree module taints kernel.
    

    Ja, ich gebe zu, das ich von dieser Materie so gut wie Null Ahnung habe. Aber auch daran muss man arbeiten 😉

    Irgend jemand eine gute Idee? Oder sieht wo ich was übersehe?

  • Dank eines Hinweises gehe ich im Moment davon aus, das die Karte China Müll ist. Die 50$ Karten sollen billige Nachbauten sein. Karte zurück gesendet!

  • ROCKPro64 - RTC

    Hardware
    1
    0 Stimmen
    1 Beiträge
    298 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Samsung Portable SSD T5 500GB

    Hardware
    1
    0 Stimmen
    1 Beiträge
    278 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - PCIe Probleme

    Hardware
    3
    0 Stimmen
    3 Beiträge
    303 Aufrufe
    FrankMF

    Danke für dein Feedback.

  • 0 Stimmen
    4 Beiträge
    359 Aufrufe
    K

    na denn, tippe ich mal so auf default konfiguriert per dhcp 🙂

  • 0 Stimmen
    1 Beiträge
    292 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Das erste Mal

    Angeheftet Verschoben Hardware
    5
    1 Stimmen
    5 Beiträge
    807 Aufrufe
    FrankMF

    Ich kann heute die Fragen aller Fragen beantworten 🙂

    Damit ist leider die Frage immer noch unbeantwortet ob WLan und PCIe zusammen nutzbar ist!! Es geht!!

    Ich habe von MrFixit ein Testimage der RecalBox, benutzt das selbe Debian wie oben. Die Tage konnte man im IRC verfolgen, wie man dem Grundproblem näher kam und wohl einen Fix gebastelt hat, damit beides zusammen funktioniert. Mr.Fixit hat das in RecalBox eingebaut und ich durfte testen.

    # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether ac:83:f3:e6:1f:b2 brd ff:ff:ff:ff:ff:ff inet 192.168.178.27/24 brd 192.168.178.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 2a02:908:1262:4680:ae83:f3ff:fee6:1fb2/64 scope global dynamic valid_lft 7145sec preferred_lft 3545sec inet6 fe80::ae83:f3ff:fee6:1fb2/64 scope link valid_lft forever preferred_lft forever # ls /mnt bin etc media recalbox sd.img test2.img boot home mnt root selinux tmp crypthome lib opt run srv usr dev lost+found proc sbin sys var # fdisk BusyBox v1.27.2 (2019-02-01 22:43:19 EST) multi-call binary. Usage: fdisk [-ul] [-C CYLINDERS] [-H HEADS] [-S SECTORS] [-b SSZ] DISK Change partition table -u Start and End are in sectors (instead of cylinders) -l Show partition table for each DISK, then exit -b 2048 (for certain MO disks) use 2048-byte sectors -C CYLINDERS Set number of cylinders/heads/sectors -H HEADS Typically 255 -S SECTORS Typically 63 # fdisk -l Disk /dev/mmcblk0: 15 GB, 15931539456 bytes, 31116288 sectors 486192 cylinders, 4 heads, 16 sectors/track Units: cylinders of 64 * 512 = 32768 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 * 2,10,9 10,50,40 32768 163839 131072 64.0M c Win95 FAT32 (LBA) Partition 1 does not end on cylinder boundary /dev/mmcblk0p2 * 16,81,2 277,102,17 262144 4456447 4194304 2048M 83 Linux Partition 2 does not end on cylinder boundary /dev/mmcblk0p3 277,102,18 1023,254,63 4456448 31115263 26658816 12.7G 83 Linux Partition 3 does not end on cylinder boundary Disk /dev/nvme0n1: 233 GB, 250059350016 bytes, 488397168 sectors 2543735 cylinders, 12 heads, 16 sectors/track Units: cylinders of 192 * 512 = 98304 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/nvme0n1p1 1,0,1 907,11,16 2048 488397167 488395120 232G 83 Linux #

    Oben sieht man eine funktionierende WLan-Verbindung, das LAN-Kabel war entfernt. Unten sieht man die PCIe NVMe SSD, gemountet nach /mnt und Inhaltsausgabe.

    Das sollte beweisen, das der Ansatz der Lösung funktioniert. Leider kann ich nicht sagen, das es zum jetzigen Zeitpunkt stabil läuft. Ich habe einfach so Reboots, kann den Fehler aktuell aber nicht fangen. Mal sehen ob ich noch was finde.

    Aber, es ist ein Anfang!

  • 0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF

    This repo contains the tn40xx Linux driver for 10Gbit NICs based on the TN4010 MAC from Tehuti Networks.

    This driver enables the following 10Gb SFP+ NICs:

    D-Link DXE-810S
    Edimax EN-9320SFP+
    StarTech PEX10000SFP
    Synology E10G15-F1
    ... as well as the following 10GBase-T/NBASE-T NICs:

    D-Link DXE-810T
    Edimax EN-9320TX-E
    EXSYS EX-6061-2
    Intellinet 507950
    StarTech ST10GSPEXNB

    Quelle: https://github.com/ayufan-rock64/tn40xx-driver/tree/master

  • SATA Karte Marvell 88SE9230 Chipsatz

    Angeheftet Hardware
    19
    0 Stimmen
    19 Beiträge
    6k Aufrufe
    FrankMF

    Ok, es gibt noch eine andere Möglichkeit.

    Kamil hat mir noch ein wenig geholfen. Mit folgender Änderung werden die Platten gefunden.

    hmm, I had to add /etc/default/extlinux: libahci.skip_host_reset=1

    Sieht dann so aus.

    # Configure timeout to choose the kernel # TIMEOUT="10" # Configure default kernel to boot: check all kernels in `/boot/extlinux/extlinux.conf` # DEFAULT="kernel-4.4.126-rockchip-ayufan-253" # Configure additional kernel configuration options APPEND="$APPEND root=LABEL=linux-root rootwait rootfstype=ext4 libahci.skip_host_reset=1"

    Danach waren die Platten zu sehen.

    root@rockpro64:/tmp/etc/default# blkid /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="ABCD-FC7D" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="72e36967-4050-4bb3-8f8f-bf6755c38f28" /dev/sda3: LABEL="linux-boot" UUID="8e289a3e-0f9b-4da1-a147-51e03390637c" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="fe944fd2-3e42-4202-8a95-656e9bdb4be6" /dev/sda4: LABEL="linux-root" UUID="3e9513c6-dfd1-48c9-bee2-04bb5a153056" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="d2d1dd88-030d-4f74-998f-7c9ce7d385d0" /dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="56C9-F745" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="919c8f73-5f25-4a01-9072-3a5ed9a88ff2" /dev/sdb3: LABEL="linux-boot" UUID="23c19647-f4a1-4197-a877-f1bb03456bef" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="093d0cc0-d122-4dce-aeb5-4e266b4b7d9d" /dev/sdb4: LABEL="linux-root" UUID="f1c74331-8318-4ee8-a4f7-f0c169fb9944" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="964ab457-58d5-40c4-bb02-dfd37bd2f0da" /dev/sda1: PARTLABEL="loader1" PARTUUID="37466429-e4a4-495c-b9a1-3f74625a3cae" /dev/sdb1: PARTLABEL="loader1" PARTUUID="33f692b3-54cb-4a37-b602-21a2baf32fa0"

    Aber auch hiermit ist ein Boot von der SATA Platte nicht möglich.

    Ich möchte hier noch was vom kamil zitieren.

    (11:44:09) ayufanWithPM: will look later, but this controller is tricky, also on x86 as well
    (11:44:16) ayufanWithPM: jms585 seems to be significantly more stable

    Evt. bekommt er das gefixt 😉