[OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
Wojciech Dubowik
Wojciech.Dubowik at neratec.com
Thu May 7 02:01:07 EDT 2015
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 at ffe00000/gpio-controller at f000
>>>> [ 2.968276] leds-gpio: probe of leds failed with error -22
>>>> [ 34.622909] /buttons/reset: could not get #gpio-cells for /soc at ffe00000/gpio-controller at 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 at 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
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list