Ankündigung

Einklappen
Keine Ankündigung bisher.

OpenWRT port with current kernel 4.16

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • IB-NAS4220-B 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
    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

    Kommentar


    • #3
      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.

      Kommentar


      • #4
        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

        Kommentar


        • #5
          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.

          Kommentar


          • #6
            @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).

            Kommentar


            • #7
              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

              Kommentar


              • #8
                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?

                Kommentar


                • #9
                  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

                  Kommentar


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

                    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 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 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 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

                    Kommentar


                    • #11
                      Zitat von sirhc Beitrag anzeigen
                      What does CurConf contain?
                      The GPL source code archive Gemini_v2_6_0-n.tgz contains the file "kernel.tgz" which contains a "redboot" folder. Inside you finde the binary images for redboot - also a VCTL partition. The archive can be found, e.g. here http://gpl.nas-central.org/RAIDSONIC/IB-NAS4220-B/


                      Zitat von sirhc Beitrag anzeigen
                      did you chance something? The orange LED is still lit all the time.
                      The naming of the LED was wrong in my first release. But once set (changed) and applied, then it works. Also after reboot. However, when you run kexec'd image, changes will not be persistent. Will verify again.

                      Zitat von sirhc Beitrag anzeigen
                      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.
                      Too bad, sorry. Used it the last times to boot zImage only.

                      Kommentar


                      • #12
                        Thank you for the info about the sources, I would have searched for ages for that. Still don't know what CurConf is used for.

                        Forget the LED issue. I could swear, I Tested this, after flashing the new Image, not with the temp loaded kernel + rootfs via kexec.

                        Kommentar


                        • #13
                          Zitat von sirhc Beitrag anzeigen
                          Forget the LED issue.
                          OK, not entirely. During boot, the orange LED turns on after initialization and stays on until you access the web interface. Only then it will indicate disc access.

                          Just as a reference for others about the issue with the message the redboot prints at startup:
                          Failed to change IP address due to illegal value
                          Failed to change IP Gateway due to illegal value
                          It doesn't seem to affect the bootloads settings. I can change the mac addresses and interface settings within the bootloader. In fact I don't know the impact of this messages, they just bother me.
                          reflashing VCTL doesn't eliminate those messages, so what ever 'illegal value' the bootloader complains about, I don't know. During my research, I found several boot logs with those messages, seemingly the appear on a number of devices using Storlink SL351x. As there doesn't seem to be any source code of that modified version of redboot, I decide not to investigate further about that.

                          Kommentar


                          • #14
                            Hi, Fist of all many thanks to SmartSmurf for working OpenWRT. It works OK AFAIK. I noticed this particular model (NAS4220) is also supported by official OpenWRT (https://downloads.openwrt.org/releas...emini/generic/). But! I'm not able to flash it. There is problem with hddapp.tgz. According to Bootloader application can be max ~5.37 MB big. SmartSmurfs port fits to this size but why official does not? This is my first OWRT project so I'm obviously missing something. Does official OWRT need different bootloader with updated memory map to allow flash bigger hddapp?

                            Name ........ FLASH addr ........ Mem addr . Datalen .. Entry point
                            BOOT ........ 0x30000000-3001FFFF 0x00000000 0x00020000 0x00000000
                            FIS directory 0x30FE0000-30FFFFFF 0x30FE0000 0x00001400 0x00000000
                            Core ........ 0x30020000-302DB353 0x01600000 0x002BB354 0x01600000
                            Ramdisk ..... 0x30320000-3091FFFF 0x00800000 0x00600000 0x00800000
                            Application . 0x30920000-30E3FFFF 0x00000000 0x00520000 0x00000000
                            CurConf ..... 0x30F40000-30FDFFFF 0x00000000 0x000A0000 0x00000000
                            VCTL ........ 0x30F20000-30F3FFFF 0x00000000 0x00020000 0x00000000


                            Thanks
                            Zuletzt geändert von koty0f; 01.10.2018, 07:32.

                            Kommentar


                            • #15
                              Your flash layout seems to be wrong
                              from vanilla linux v4.19-rc5
                              Code:
                                  soc {
                                      flash@30000000 {
                                          status = "okay";
                                          /* 16MB of flash */
                                          reg = <0x30000000 0x01000000>;
                              
                                          partition@0 {
                                              label = "RedBoot";
                                              reg = <0x00000000 0x00020000>;
                                              read-only;
                                          };
                                          partition@20000 {
                                              label = "Kernel";
                                              reg = <0x00020000 0x00300000>;
                                          };
                                          partition@320000 {
                                              label = "Ramdisk";
                                              reg = <0x00320000 0x00600000>;
                                          };
                                          partition@920000 {
                                              label = "Application";
                                              reg = <0x00920000 0x00600000>;
                                          };
                                          partition@f20000 {
                                              label = "VCTL";
                                              reg = <0x00f20000 0x00020000>;
                                              read-only;
                                          };
                                          partition@f40000 {
                                              label = "CurConf";
                                              reg = <0x00f40000 0x000a0000>;
                                              read-only;
                                          };
                                          partition@fe0000 {
                                              label = "FIS directory";
                                              reg = <0x00fe0000 0x00020000>;
                                              read-only;
                                          };
                                      };
                              Kernel is 3 MB, Ramdisk and Hddapp is 6MB in size

                              And this seem to be the original size,
                              as I'm remember this thing.
                              Some random kernel coder
                              Lots of stuff attached to serial console
                              https://github.com/ulli-kroll

                              Kommentar

                              Lädt...
                              X