Device-tree improvements

[TheSaint]

Wifi is working only for simple request. STA and AP will crash the cfg80211 module.
Anyway it is like mainlined kernel gave it.
I rather worry about the UMS, which is not detected.

[summers]

Is the WiFi behaviour different in my patch than it was in the Tinkerboard debian distribution? I have this nagging worry that the RTL8723BS is in staging, that driver is down to be removed, when it can be rewritten in the new style. That to me means that there will be little or no development on the current driver - that would be waisted effort ...

The SD card issues is odd, your last log showed it ejected, and only 0.5s later did the auto probing start going wild. This says to me something odd going on - I don't yet understand it.

[TheSaint]

For the rtl8732bs I can't imaging what the ASUS staff arranged. But is disappointing that they propose a OS with several patches.
So if I put into AP mode, it will surrender the cfg80211 module unusable.
$this->bbcode_second_pass_code('', '[ 668.921526] [<bf1245e4>] (cfg80211_new_sta [cfg80211]) from [<bf28d660>] (rtw_cfg80211_indicate_sta_assoc+0x74/0x90 [r8723bs])
[ 668.934348] [<bf28d660>] (rtw_cfg80211_indicate_sta_assoc [r8723bs]) from [<bf2493ec>] (rtw_stassoc_event_callback+0x1ac/0x1c4 [r8723bs])
[ 668.948230] [<bf2493ec>] (rtw_stassoc_event_callback [r8723bs]) from [<bf2539a8>] (mlme_evt_hdl+0x74/0xa8 [r8723bs])
[ 668.960070] [<bf2539a8>] (mlme_evt_hdl [r8723bs]) from [<bf23f5f8>] (rtw_cmd_thread+0x184/0x3c4 [r8723bs])
[ 668.970900] [<bf23f5f8>] (rtw_cmd_thread [r8723bs]) from [<c0369360>] (kthread+0x148/0x150)')
I think we won't have much chances.
But for a certain condition I can manage to use TB as I need it. I don't know whether there will be more Tinkerer looking to install a mainlined kernel.

[summers]

That looks like a partial kernel dump. Means that the kernel has barfed. I'd probably put that down to the WiFi driver, e.g. doesn't seem to point at a fault in the device tree. My guess is as the chip is still being used on new hardware that its good chance it will be rewritten at some stage.

[TheSaint]

Oh, I found the MCU manual
Maybe I'll learn something.

[summers]

Yes, the Technical Reference Manual gives most of the details needed to write a device tree. That said rockchip seem to have gaps in them, e.g. on the rk3328 can't find the watchdog clock, also can see at first glace on the rk3288 ...

[summers]

@TheSaint

Oh yes forgot to ask. Does your TBS has a /dev/watchdog device?

From problems on the rk3328 and looking at clocks on the rockchip devices, it seems clear that as regards the watchdog, the kernel is a bit of a mess. So half thinking of starting a discussion on the linux rockchip mail list - to see if we can fix *all* rockchip devices. Anyway would help to know if the rk3288 is working ...

[TheSaint]

From linaro installation, rk3288-miniarm.dtb$this->bbcode_second_pass_code('', '$ ls /proc/device-tree/watchdog@ff800000/
clocks compatible interrupts name phandle reg status')
IIRC, the TRM mention the watchdog, probably 2.

[summers]

What about /dev/watchdog?

Your device tree has clocks defined, and I think thats whats missing on other rockchip set up. If your kernel is fine with the watchdog you should get /dev/watchdog created.

Maybe also try:
$this->bbcode_second_pass_code('', 'dmesg | grep dw_wdt')
That should show the kernel driver coming up ...

[TheSaint]

Not found$this->bbcode_second_pass_code('', '$ dmesg | grep dw_wdt
linaro@tinkerboard:~$')