On Thu, May 7, 2015 at 8:01 AM, Wojciech Dubowik
<wojciech.dubo...@neratec.com> wrote:
> On 06/05/15 21:23, Heiner Kallweit wrote:
>>
>> Am 05.05.2015 um 22:17 schrieb Heiner Kallweit:
>>>
>>> Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
>>>>
>>>> On 04/05/15 22:45, Heiner Kallweit wrote:
>>>>>
>>>>> I tried to make the TL-WDR4900 work under kernel 4.0.
>>>>> Adjusting the platform-specific patches was quickly done and the system
>>>>> boots.
>>>>> However I get the following error messages.
>>>>>
>>>>> [ 2.959975] /leds/system: could not get #gpio-cells for
>>>>> /soc@ffe00000/gpio-controller@f000
>>>>> [ 2.968276] leds-gpio: probe of leds failed with error -22
>>>>> [ 34.622909] /buttons/reset: could not get #gpio-cells for
>>>>> /soc@ffe00000/gpio-controller@f000
>>>>> [ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
>>>>> [ 34.637657] gpio-keys: probe of buttons failed with error -22
>>>>>
>>>>> I'm not a device tree expert, what I checked so far:
>>>>> The gpio-related section in tl-wdr4900-v1.dts is empty
>>>>>
>>>>> gpio0: gpio-controller@f000 {
>>>>> };
>>>>
>>>> Gpio controller is now at fc00. See latest commit for
>>>> arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
>>>> Regards,
>>>> Wojtek
>>>>
>>>> PS. I have been also trying 4.0 but I have ran into so many problems
>>>> with gianfar that I have given it up.
>>>> For now...
>>>
>>> Thanks. I face issues with the network as well and had to attach a serial
>>> console + tftpboot to make it work again.
>>> Back to 3.19.0 now ..
>>>
>>> Heiner
>>>
>> I gave it one more try and replaced the gianfar driver from 4.0.1 with the
>> one from 3.19.0. Results:
>> - When rebooting first time after flashing the system (4.0.1) came up
>> properly and was reachable via network.
>> - After next reboot: system hangs
>> Booting the failing system with a serial console attached shows that after
>> "procd -init-" nothing happens.
>> I can log in via serial console. ps -ef showed that
>> /etc/rc.d/S00sysfixtime was hanging.
>> Checking the commands in this script manually I figured out that each
>> access to "/etc/uci-default" blocks the console.
>>
>> Seems like the first start after flashing the system does something bad
>> with /etc/uci-defaults.
>> Or for whatever reason something can't deal properly with the empty
>> /etc/uci-defaults after the second boot.
>> No clue whom to blame ..
>
> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
> readdir. As far as I remember
> with this patch it went through but I don't know anymore whether I have
> changed sth in config.
>
> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for spi
> nor flash.
>
> Even with this patch I got some possible dead lock warnings so it might be
> just a partial cure. BTW it's
> a bit scary for future use. Looks like jffs2 doesn't get enough care...
>
> Regards,
> Wojtek
>>
>>
>> Heiner
>>
>
Thanks for the hints!
Because you mentioned that you have lots of problems with gianfar
under 4.0: what kind of problems?
Heiner
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
