Hi, since I am testing at the moment for a new devicetree description to let the nsa3xx-hwmon kernel module recognize the nsa320 mcu I have here two nsa320 boxes, where I can provoke exactly the same situation with phy not powered which you are experiencing at the moment here with the nsa310s, the first nsa320 box has vendor uboot, the other bodhi's newest uboot, both with debianby pbg4 - Debian
Hi bodhi, yes you are right, but if gpio 26 is the data pin, we would need to identify the clock pin too,.. if zyxel has used the nsa320 scheme to activate the phy in the same way on the nsa310s, so one could use the same rc.local based approach as on the nsa320,.. but the protocols pengu just posted show that they are poking register settings on startup, to activate the phy, that'sby pbg4 - Debian
Hi, on the NSA320 phy is powered if power_resume is on, but it does not help to simply write 1 to power_resume_data, you must give the power_resume_clk a transition from 1 to 0, only than the data pin is read, so if you put something into rc.local like this on the NSA320 power_resume is switched on at boot, if you shutdown the device than, take of the powerplug for a couple of seconds,by pbg4 - Debian
Hi bodhi, perhaps it is best to give an example what should be done in kirkwood-nsa320.dts, in devicetree nomenclature it should be as simple as that code snippet below, that would be all that is to be done basically, to get nsa3xx-hwmon going, (beware, the code snippet is just an example of how it should be done, it will not work!!) however: ----> there is no compatible descriptiby pbg4 - uBoot
Hi, in the newer devicetree enabled linux kernels from linux-3.18.5 onwards, the hwmon nsa3xx module for the NSA320 is not working, because the gpio pins 14, 16, 17 which are the relevant gpios for the pmx_mcu_data, pmx_mcu_clk, pmx_mcu_act signals of the mcu are not exposed outside via compatible descriptions to the nsa3xx driver, see kirkwood-nsa320.dts,.. I have looked into thby pbg4 - uBoot
Hi, on both of my NSA320 boxes the resistor mod is used to calm the original fan down to a reasonable value, but nevertheless here are some hints if somebody has time and wants to look a little bit into the details,.. if you look in the original sources which were published by zyxel you see how to read out the mcu status in mcu.c ,.. and the datasheet of the holtek mcu is also easily foby pbg4 - Debian
Hi bodhi, I just send the patch for linux-4.1 for dvb-usb-dw2102 to you per pm, please have a look, as stated before it is rather small, because most of the changes are upstream and contained in linux 4.1,.. it would also be a good idea to put the newest frontend firmware for m88ds3103 into your next rootfs, in /lib/firmware, it is also attached in the pm, md5sum should be b31080dd205ce1by pbg4 - Debian
Hi bodhi, on kernel.org linux kernel 4.1 was finally released today, a first look at the relevant sources for the dvb-usb-dw2102 kernel module and Integration of various usb dvb-s2 adapters revealed that most of the changes of Olli Salonen for that driver got upstream,.. so the tt-s2-4600 is supported from now on!!,... but a small patch is still needed - instead of my big patch includedby pbg4 - Debian
Hi, since - with the aid of bodhis new uboot and kernel/rootfs - it is now possible to boot the NSA320 from an usb port and have an internal software raid on the two sata ports, only one problem arises, there are only two usb ports on the back of the device left, although the data sheet of the usb hub on the main pcb documents that there are 4 downstream ports, the NSA320 has an internaby pbg4 - Debian
Hi bodhi, a quick comparison of kirkwood-nsa320.dts and the more complete kirkwood-nsa325.dts revealed already most of the differences which have to be adapted for the nsa320 in the dts file, because both devices have many design similarities, as you own a nsa325, is the nsa3xx-hwmon included in linux-4.0.0-kirkwood-tld-2driver working for you properly with the nsa325 ??,.. than it shouby pbg4 - Debian
Hi, the nsa3xx-hwmon is included in linux-4.0.0-kirkwood-tld-2, but the problem is, with the kirkwood-nas320.dts description, the GPIO's for the holtek mcu microprocessor which controls the fan and temperature sensor in the NSA320 are no longer exposed to the outside driver world, i.e mcu_data, mcu_clk, mcu_act /* The following pins are currently not assigned to a driver,by pbg4 - Debian
Hi bodhi, this is just another verification that your latest uBoot i.e. NSA320 u-boot 2014.07-tld-3 image worked fine with uart booting and kwboot on a NSA320 box here, so I flashed it and configured the uboot envs and its running properly with only minor issues, (see below), to everybody else who also tries this, please use the latest tools from ftp://ftp.denx.de/pub/u-boot/u-boot-2015.by pbg4 - uBoot
Hi, @bodhi some news about the dvb driver situation, especially dvb-usb-dw2102, in the last days I have received emails from Olli Salonen, one of the devs from linux-media, he has finally found the last bug of the tt-s2-4600 driver (inside dvb-usb-dw2102) which has found its way in linux kernel 4.1-rc1 in the merge window and asked me to make tests, my tests today of these commitsby pbg4 - Debian
Hi, concerning systemd I have the same mixed feelings about it as bodhi has, so I am not holding my breath to see it arrive in armv5 kirkwood mainline land, perhaps we should wait a little bit, sometime things get more mature that way, and than it's easier to adopt and integrate it, but of course its the way it goes, as debian is following that path,.. best wishes pbg4by pbg4 - Debian
Hi bodhi, at the moment my recompile is running for 4.1-rc1 where I adopted your patch, hopefully I can get it working now with the full config, as it is already working now with multi_v5_defconfig, because in the merge window of 4.1 there was a git pull from linux-media done everything is contained already, this makes my old patch superfluous, the tt-s2-4600 is from 4.1 onwards supporby pbg4 - Debian
Hi bodhi, success, that patch did it,!! wlan via pcie is back in my iconnect with 4.1-rc1 and the small config, i.e. multi_v5_defconfig, see: pci 0000:00:01.0: enabling device (0140 -> 0142) ath: phy0: Enable LNA combining ath: EEPROM regdomain: 0x60 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x60 ieee8021by pbg4 - Debian
Hi bodhi, somebody did already a kernel bisect and perhaps found the guilty commit, see here: http://www.spinics.net/lists/arm-kernel/msg413993.html I am just testing the patch and recompile best wishes pbg4 p.s. the kernel compile with multi_v5_defconfig was also not successfull as already expectedby pbg4 - Debian
Hi bodhi, applied the patch manually and recompiled zImage and later generated uImage made 4.1-rc1 kernel boot, OK, but not really since at the time when init initiates the rootfs a segmentation fault occurs,.. this test was done with a config similar to your standard config (only dynamic debugging enabled, and than make oldconfig) but without the 3.18.5 patch applied to 4.1-rc1, becauby pbg4 - Debian
Hi bodhi, the same here, but Andrew Lunn has already issued a patch, http://www.spinics.net/lists/arm-kernel/msg414799.html now a recompile of the kernel is running here, will take some time ,.. best wishes pbg4by pbg4 - Debian
Hi bodhi, as you may already have noticed, 4.1-rc1 is out, a first glance showed lots of interesting changes, also to the pci host driver pci-mvebu.c,.. also the mvebu_v5_defconfig is gone, now there is only a multi_v5_defconfig left, what I had still on my list was to start with a minimal config based on multi_v5_defconfig and beside CONFIG_PCI_MVEBU skip everything not necessary in theby pbg4 - Debian
Hi, @bodhi are we missing something in the armv5 config for 4.0.0 which should be there? CONFIG_HOTPLUG_PCI_PCIE=y this is part of the ubuntu mainline ppa patch for ubuntu 4.0.0-1.1, of course nobody wants to hotplug pcie devices in armv5, but there are commits for 4.0.0 that enable this dependent on acpi, which on armv5 is not an issue, just a thought,... best wishes pbg4by pbg4 - Debian
Hi, if time permits I am also going have a look at the commits between 3.19.5 and 4.0.0-rc1, perhaps we should also have a look if new kernel options were introduced with 4.0.0-rc1 in the kernel docs, if perhaps a new enumeration scheme for probing of devices on the pci bus scan can be switched back to the older legacy method before 4.0,.. the congenio image and rootfs is simply a debianby pbg4 - Debian
Hi bodhi, there was a recent git pull of pci-v4.0-fixes-3 whithin the merge window of 4.0 here: https://lkml.org/lkml/2015/4/9/533 but looking at the patches,.. nothing spectacular so far which looks suspicious, the only kernel I could try inbetween was 3.19.1, that was fine and did not have the regression, so perhaps 3.19.4 would be fine too, or should we test 4.0.0-rc7 to see the eby pbg4 - Debian
Hi, @bodhi yes, that's what I would suspect also, something went wrong after the initialisation of pci/pcie and the probing of devices afterwards, according to dmesg messages of kernel 3.18.5 and 4.0.0 its all identical, only difference is, the probing after: pci 0000:00:01.0: enabling device (0140 -> 0142) goes wrong with kernel 4.0.0, and the usb 3.0 chip of Pogoplug V4 anby pbg4 - Debian
Hi, sorry but the same situation here after updating one of two iconnects, this one with an AR9285 Wireless Network Adapter (PCI-Express) which was fine with 3.18.5, same problem,.. there is something wrong with pcie,.. and initialisation of socs attached to pcie,.. [ 17.580843] pci 0000:00:01.0: enabling device (0140 -> 0142) [ 17.772134] ath: phy0: Couldn't reset chip [by pbg4 - Debian
Hi bodhi, absolutely right, but as gaogao is using an NSA320 box, it is not so easy to get a netconsole enabled uboot, I am back on my NSA320 boxes to the factory version without netconsole, because I had timing issues with booting an internal sata ssd, documented elsewhere in this forum, neither davygravy's uboot or the other uboot versions tested could boot my SanDisk SDSSDP064G, alby pbg4 - Debian
Hi, @gaogao hmm,.. interesting to see this effect of the kernel dma coherent pool size, unfortunately there is a config parameter to enable the coherent dma pool, i.e. CONFIG_HAVE_GENERIC_DMA_COHERENT=y but no parameter to change its initial size,.. I think that with a serial converter you would be better off, since if you stop the boot phase with the serial converter attached, you caby pbg4 - Debian
Hi, @gaogao the best way to test this right from the early boot phase is to create a file dvb.conf in /etc/modprobe.d with something like options dvb-usb-it913x debug=1 options it913x-fe debug=1 in it and look what you get in dmesg, with the firmware parameter you can also test if you have a different hardware version, see below modinfo /lib/modules/3.13.1-kirkwood-tld-2/kerneby pbg4 - Debian
Hi, @gaogao please load the module with the info=1 option, perhaps in the it913x_io io routine there is something wrong with the kernel allocation of usb buffers, with info=1 you would see something like info "USB Buffer Failed",.. or try to check what the error -12 means, by checking the error -12 ENOMEM value, best wishes pbg4by pbg4 - Debian
Hi, @gaogao according to your log files the frontend kernel module it913x-fe is not loaded, but it is included in the config, the relevant module for the rc-core system is also not loaded, i.e. rc-it913x-v2, what happens when you load the frontend by hand? best wishes pbg4by pbg4 - Debian