Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: OpenWRT port with current kernel 4.16

  1. #1
    Cadet
    Registriert seit
    28.03.2018
    Ort
    Frankfurt / Main
    Beiträge
    8
    Mein NAS
    IB4220 Rev 1.1 + Rev 1.21

    Standard OpenWRT port with current kernel 4.16

    Hi all,

    maybe you have noticed - Linux kernel supports Gemini SoC 351x upstream since release 4.16.

    I built latest OpenWRT with most recent kernel.

    Please find the release here: https://github.com/Smartsmurf/openwr...lease_20180513

    It is compatible with the Raidsonic update process, so you could also revert back to the original firmware.

    Some features:
    • filesystems as kernel modules EXT4, BTRFS, XFS
    • GPT support
    • Raid support (0, 1 and 10, mdadm)
    • Samba 3.6
    • Gerbera 1.2 (UPnP / DLNA server)


    Tested on both board revisions 1.1 and 1,21.

    Disclaimer: I take no responsibility for bricked/damaged devices.

    Best regards.

  2. #2

    Standard

    Hi,

    first of all: Thank you all for the effort you all put into this project, to keep alife a ten years old hardware. I just recently got to this subject since I found a IB4220 with a messed up flash file system in the trash and curiosity got me.

    I hadn't had much time yesterday to test, but here are my fist observations. Most things look fine but there are some glitches:

    Ther are repeatedly messages around the ata interfaces:
    Code:
    [    7.857636] pata_ftide010: Unexpected interrupt
    and a message regarding the network interface:
    Code:
    [    8.626256] mdio-gpio ethernet-phy: failed to get alias id
    About every 3rd boot my device (hw rev 1.1 by the way) turn off during usb initialisation by itself:
    Code:
    [    9.590610] pinctrl-gemini 40000000.syscon:pinctrl: ACTIVATE function "usb" with group "usbgrp"
    [    9.643821] fotg210-ehci 68000000.usb: resetting fotg2xx
    [    9.730060] fotg210-ehci 68000000.usb: initializing Gemini PHY @ 0x68000000 (val=0x400000, mask=0x20004000)
    [    9.788526] fotg210-ehci 68000000.usb: initialized Gemini PHY
    [    9.823152] fotg210-ehci 68000000.usb: EHCI Host Controller
    [    9.857454] fotg210-ehci 68000000.usb: new USB bus registered, assigned bus number 1
    [    9.904336] fotg210-ehci 68000000.usb: fotg2_ehci_reset called
    [    9.940232] fotg210-ehci 68000000.usb: Received unexpected irq for OTG management
    [    9.985425] fotg210-ehci 68000000.usb: irq 29, io mem 0x68000000
    [   10.021659] fotg210-ehci 68000000.usb: USB 2.0 started, EHCI 1.00
    [   10.059165] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
    [   10.100114] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    [   10.143505] usb usb1: Product: EHCI Host Controller
    [   10.172824] usb usb1: Manufacturer: Linux 4.16.3 ehci_hcd
    [   10.205257] usb usb1: SerialNumber: 68000000.usb
    [   10.235295] hub 1-0:1.0: USB hub found
    [   10.258627] hub 1-0:1.0: 1 port detected
    [   10.285903] pinctrl-gemini 40000000.syscon:pinctrl: ACTIVATE function "rtc" with group "rtcgrp"
    [   10.340988] rtc-ftrtc010 45000000.rtc: rtc core: registered 45000000.rtc as rtc0
    [   10.387435] pinctrl-gemini 40000000.syscon:pinctrl: ACTIVATE function "power" with group "powergrp"
    [   10.443253] gemini-poweroff 4b000000.power-controller: poweroff button pressed
    [   10.487182] gemini-poweroff 4b000000.power-controller: Gemini poweroff driver registered
    [   10.536107] reboot: Failed to start orderly shutdown: forcing the issue
    [   10.576711] Emergency Sync complete
    [   10.598558] reboot: Power down
    [   10.619329] ftwdt010-wdt 41000000.watchdog: FTWDT010 watchdog driver enabled
    [   10.661883] gemini-poweroff 4b000000.power-controller: Gemini power off
    ...and I dind't pressed any button.

    Sadly the serial console doesn't work after boot since /sbin/getty is missing, but it's possible to connect via ssh.

    After a few boots the webinterface broke down, sadly I misplaced the message, but I'll try the recreate the condition.

    The yellow hdd led is constantly lit, Is that on purpose?

    Some other stuff probably not related to the new software:

    Immediately after turning on the device I get these messages on the serial console:
    Code:
    Failed to change IP address due to illegal value
    Failed to change IP Gateway due to illegal value
    and the nas has a funny mac address 00:50:C2:11:11:11
    I suppose this has something to do with messed up stuff in the flash?
    Does someone know the purpose of the two files 'VCTL' and 'CurConf'?

    I attached two boot logs, one with hdd's one without

    Cheers,
    Christian
    Angehängte Dateien Angehängte Dateien

  3. #3
    Cadet
    Registriert seit
    28.03.2018
    Ort
    Frankfurt / Main
    Beiträge
    8
    Mein NAS
    IB4220 Rev 1.1 + Rev 1.21

    Standard

    Thank you for the time and the feedback, too.

    Regarding the ata interface: the "pata_ftide010: Unexpected interrupt" message comes from some leftover debug code. The source seems to origin from the silicone. I see these entries with my rev 1.1. board, too. But I don't encounter this on rev 1.21. Some years ago there were discussions in this forum about spurious ata IRQs.. Anyway I am going to remove the logging.

    mdio-gpio ethernet-phy: failed to get alias id

    Good catch. The alias is definitely missing in the dts file.

    This is how MAC addresses are read from VCTL
    Code:
    set_ether_mac() {
        CONFIG_PARTITION="$(grep "VCTL" /proc/mtd | cut -d: -f1)"
        MAC1="$(strings /dev/$CONFIG_PARTITION |grep MAC|cut -d: -f2|cut -c3-14|sed -e 's,\(..\),:\1,g' -e 's,^:,,')"
        MAC2="$(strings /dev/$CONFIG_PARTITION |grep MAC|cut -d: -f8|cut -c3-14|sed -e 's,\(..\),:\1,g' -e 's,^:,,')"
    
    
        ifconfig eth0 hw ether $MAC1 2>/dev/null
        ifconfig eth1 hw ether $MAC2 2>/dev/null
    }
    The messages you see "Failed to change..." stems from the redboot bootloader.

    The orange LED should be coupled to disk activity. I'll check config.


  4. #4
    Experte
    Registriert seit
    27.03.2008
    Ort
    Cologne / Germany
    Beiträge
    4.938
    Mein NAS
    N2B1 & IB4220 & WNDR3700v2 with OpenWRT

    Standard

    Can you please and report this here with vanilla sources from OpenWRT ?

    THANKS
    Some random kernel coder
    Lots of stuff attached to serial console
    https://github.com/ulli-kroll

  5. #5
    Cadet
    Registriert seit
    28.03.2018
    Ort
    Frankfurt / Main
    Beiträge
    8
    Mein NAS
    IB4220 Rev 1.1 + Rev 1.21

    Standard

    Zitat Zitat von ElektromAn Beitrag anzeigen
    Can you please and report this here with vanilla sources from OpenWRT ?

    THANKS
    My repo is synced with OpenWRT repo. However OpenWRT is using kernel 4.14 with backported Cortina Gemini code from Kernel 4.16. That's why I directly headed towards that newer kernel version.

  6. #6
    Cadet
    Registriert seit
    28.03.2018
    Ort
    Frankfurt / Main
    Beiträge
    8
    Mein NAS
    IB4220 Rev 1.1 + Rev 1.21

    Standard

    @sirhc: Please find the update here: https://github.com/Smartsmurf/openwr...0_20180515.zip

    I added /sbin/getty, too.

    You might try the release via "kexec" first. For that reason I added a folder with all required files in it (basically zImage without DTB appendix and cpio filesystem).

  7. #7
    Experte
    Registriert seit
    27.03.2008
    Ort
    Cologne / Germany
    Beiträge
    4.938
    Mein NAS
    N2B1 & IB4220 & WNDR3700v2 with OpenWRT

    Standard

    Zitat Zitat von SmartSmurf Beitrag anzeigen
    My repo is synced with OpenWRT repo. However OpenWRT is using kernel 4.14 with backported Cortina Gemini code from Kernel 4.16. That's why I directly headed towards that newer kernel version.
    I know this.

    But next OpenWRT -stable release will be with 4.14.x, in a couple months.
    We need some broader use cases ...

    This will benefit user experience.
    Also please tell about the missing alias in DT
    Some random kernel coder
    Lots of stuff attached to serial console
    https://github.com/ulli-kroll

  8. #8
    Cadet
    Registriert seit
    28.03.2018
    Ort
    Frankfurt / Main
    Beiträge
    8
    Mein NAS
    IB4220 Rev 1.1 + Rev 1.21

    Standard

    OK, makes sense. However as of today running a NAS4220 port with the patches provided for 4.14 will bring issues.
    What is the best way to send patches?

  9. #9
    Experte
    Registriert seit
    27.03.2008
    Ort
    Cologne / Germany
    Beiträge
    4.938
    Mein NAS
    N2B1 & IB4220 & WNDR3700v2 with OpenWRT

    Standard

    Zitat Zitat von SmartSmurf Beitrag anzeigen
    OK, makes sense. However as of today running a NAS4220 port with the patches provided for 4.14 will bring issues.
    What is the best way to send patches?
    Either direct via mailing lists (*), or
    I do add your tree to mine (locally), so I can check these and send them off to mailing list.
    included Signed-off-by/tested-by/reviewed-by (if you wish)

    (*)
    for this you need to know how to generate proper patches, including the format
    Some is in Documentation/process of your linux kernel source tree,
    Other part is in https://openwrt.org/submitting-patches

    And of course your *real* name including mail address.
    But this is described in both places/links I gave you.
    ... more or less, for OpenWRT the latter one ;-)
    Some random kernel coder
    Lots of stuff attached to serial console
    https://github.com/ulli-kroll

  10. #10

    Standard

    Thank you for the update, my last two day where very busy.

    Zitat Zitat von SmartSmurf Beitrag anzeigen
    Regarding the ata interface: the "pata_ftide010: Unexpected interrupt" message comes from some leftover debug code. The source seems to origin from the silicone. I see these entries with my rev 1.1. board, too. But I don't encounter this on rev 1.21. Some years ago there were discussions in this forum about spurious ata IRQs.. Anyway I am going to remove the logging.
    Code:
    mdio-gpio ethernet-phy: failed to get alias id

    Good catch. The alias is definitely missing in the dts file.

    those two messages are gone.

    About the purpose of VCTL and CurConf:
    Zitat Zitat von SmartSmurf Beitrag anzeigen
    The messages you see "Failed to change..." stems from the redboot bootloader.

    I know that "Failed to change..." stems from the bootloader. So at least VCTL contains informations about bootloader settings (a seemingly crude but efficient way to the the mac addresses). My guess is, that there is somehow corrupt data within this file, leading to this message. Do you know of a way to fix this, maybe cloning this data from an other device?
    What does CurConf contain?

    Zitat Zitat von SmartSmurf Beitrag anzeigen
    The orange LED should be coupled to disk activity. I'll check config.
    did you chance something? The orange LED is still lit all the time.
    When I browsed though the web interface I found that the disk LED is configured wrong by default:
    LED Name 'nas4220b:green:os' instead of 'nas4220b:orange:hdd' although '/etc/config/system' contains the correct information. Changing this within the web interface will in fact turn the LED of, indicating hdd acces furthermore (tested), but after a reboot, it's wrong again.
    So it's not your config, but probably the upsteam code.

    Zitat Zitat von SmartSmurf Beitrag anzeigen
    You might try the release via "kexec" first. For that reason I added a folder with all required files in it (basically zImage without DTB appendix and cpio filesystem).
    Your 'run_kexec.sh' script doesn't work. I hat to omit '--image-size' and change it, so that the whole kexec command is executed at once.
    Code:
    #!/bin/sh
    
    tmp_var="kexec -d -l /tmp/openwrt-gemini-raidsonic-nas4220-zImage \
      --dtb=/tmp/gemini-nas4220b.dtb"
    
    if [ -f "/tmp/openwrt-gemini-raidsonic-rootfs.cpio.gz" ]; then
      tmp_var="${tmp_var} --initrd=/tmp/openwrt-gemini-raidsonic-rootfs.cpio.gz \
        --command-line=\"console=ttyS0,19200n8 root=/dev/ram0\""
    fi
    
    eval "$tmp_var"
    
    echo waiting 20 sec...
    sleep 20
    kexec -e

Ähnliche Themen

  1. IB-NAS4220-B OpenWRT port with current kernel 3.0.1
    Von tobias.waldvogel im Forum Custom Firmware
    Antworten: 1700
    Letzter Beitrag: 13.05.2018, 22:58
  2. S.M.A.R.T. Current Pending Sector Count
    Von ukulele im Forum Festplatten
    Antworten: 3
    Letzter Beitrag: 28.02.2013, 07:42
  3. IB-NAS4220-B Running a current debian testing
    Von abalone im Forum Complex Solutions and Lessons Learned
    Antworten: 1
    Letzter Beitrag: 10.09.2012, 12:01
  4. IB-NAS4220-B OpenWRT port with current kernel 3.0.1
    Von tobias.waldvogel im Forum Development
    Antworten: 277
    Letzter Beitrag: 19.12.2011, 11:41

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •