Device-tree improvements

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'B')est to either write an overlay

[summers]

I think this thread: https://archlinuxarm.org/forum/viewtopic.php?f=23&t=12635 explains it best - overlays are used hugely on beagle boards - but other arm boards don't use overlays so much. So the thread on beagles is the way to go.

Me though, if developing code for an overlay, I'd have uboot write the changes to the device tree - as thats quick to check if it works.

[TheSaint]

Latest new....
I got last kernel$this->bbcode_second_pass_code('', '$ uname -a
Linux alarm 4.19.4-1-ARCH #1 SMP PREEMPT Sun Nov 25 17:14:23 UTC 2018 armv7l GNU/Linux')And it seems to work flawlessly
There's no bluetooth yet . But it may take to set rtw_btcoex_enable=1 to enable it. I'll try soon.

One more surprise$this->bbcode_second_pass_code('', '$ dmesg |grep -i rtc
[ 2.403208] rk808-rtc rk808-rtc: registered as rtc0
[ 2.522200] rk808-rtc rk808-rtc: setting system clock to 2018-11-27 02:15:19 UTC (1543284919)

$ ls /dev/rtc
rtc rtc0 ')
The clock is fine without any additional interventions.

EDIT
Trying hostapd I get this crash$this->bbcode_second_pass_code('', '[ 167.524578] ------------[ cut here ]------------
[ 167.529738] kernel BUG at mm/slub.c:3901!
[ 167.534203] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 167.540716] Modules linked in: 8021q garp mrp stp llc realtek snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils snd_soc_rockchip_i2s snd_soc_rockchip_pcm snd_soc_core ac97_bus snd_pcm_dmaengine r8723bs(C) dw_wdt rk_crypto snd_usb_audio snd_usbmidi_lib evdev snd_hwdep cfg80211 joydev snd_rawmidi snd_seq_device snd_pcm rfkill snd_timer pwm_rockchip dwmac_rk stmmac_platform stmmac rockchipdrm analogix_dp dw_hdmi cec rockchip_saradc rc_core uio_pdrv_genirq uio sch_fq_codel crypto_user ip_tables x_tables
[ 167.595282] CPU: 1 PID: 286 Comm: RTW_CMD_THREAD Tainted: G C 4.19.4-1-ARCH #1
[ 167.604804] Hardware name: Rockchip (Device Tree)
[ 167.610058] PC is at kfree+0x190/0x1b4
[ 167.614276] LR is at nl80211_send_station+0xa6c/0xc70 [cfg80211]
[ 167.620974] pc : [<c04a7d80>] lr : [<bf1740ac>] psr: 40010013
[ 167.627971] sp : ec1e3da0 ip : 00000010 fp : eb0f5014
[ 167.633804] r10: 00000000 r9 : eb0f5030 r8 : 00000580
[ 167.639635] r7 : ec1e3e50 r6 : ef4d6e20 r5 : ec7c5cc0 r4 : c1605d88
[ 167.646924] r3 : 00000100 r2 : 00000024 r1 : ecee7a4c r0 : f0d48000
[ 167.654214] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 167.662182] Control: 10c5387d Table: 2c27406a DAC: 00000051
[ 167.668598] Process RTW_CMD_THREAD (pid: 286, stack limit = 0x25374805)
[ 167.675976] Stack: (0xec1e3da0 to 0xec1e4000)
[ 167.680839] 3da0: 00000011 ec1e3e50 c1605d88 ec7c5cc0 00000011 ec1e3e50 00000580 bf1740ac
[ 167.689976] 3dc0: 00000005 00000013 eb0f5014 00000000 ffff7eac c1605d88 eb0f5034 eb0f5030
[ 167.699102] 3de0: 00000000 00000000 00000000 552df228 000101d8 ec4d0000 00480020 ecee7a0a
[ 167.708238] 3e00: ec1e3e50 ec4d31a0 00000000 ec7c5cc0 ffff7eac bf17444c 00000000 ec4d3000
[ 167.717374] 3e20: ec4d0000 ecee7a0a ec1e3e50 c1605d88 c1605d88 0000001c 00000000 00000000
[ 167.726502] 3e40: eb0c1100 f0d49450 f0d48000 bf281238 00000000 00000000 ed024600 552df228
[ 167.735638] 3e60: 00000065 f0d48000 00000004 c1605d88 00000001 bf2393ec 00000065 bf265138
[ 167.744774] 3e80: ef406854 00000000 8020001b eb0adf00 eb0ad580 c04a76b8 00000001 8020001a
[ 167.753910] 3ea0: 00000001 00000006 c1605d88 eb0adf00 00000000 f0d48000 ecee7a1c 00000030
[ 167.763047] 3ec0: 006c6048 8020001a 00000fff 552df228 f0d48000 552df228 00000000 ee001d00
[ 167.772183] 3ee0: eb0adf00 ef406854 ffffe000 00008409 f0d49450 f0d48000 001fff00 ffffe000
[ 167.781319] 3f00: 0000004c 552df228 ffff7eac f0d48000 f0ddb3b4 0000004c ecee7a00 bf23d2c8
[ 167.790446] 3f20: f0d48000 00000000 f0d49470 c1604d00 eb0c1100 bf247888 f0d49000 f0d4b000
[ 167.799582] 3f40: f0d49470 bf2335f0 ed3aee78 60070013 ec1e2000 ec4d5200 bf298000 f0d49460
[ 167.808710] 3f60: ec50ca9c ec50ca80 ecc9af00 00000000 ec1e2000 f0d48000 bf23346c ec1efcbc
[ 167.817845] 3f80: ec50ca9c c0364aac 00000020 ecc9af00 c0364964 00000000 00000000 00000000
[ 167.826981] 3fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000
[ 167.836108] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 167.845244] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 167.854407] [<c04a7d80>] (kfree) from [<bf1740ac>] (nl80211_send_station+0xa6c/0xc70 [cfg80211])
[ 167.864296] [<bf1740ac>] (nl80211_send_station [cfg80211]) from [<bf17444c>] (cfg80211_new_sta+0x6c/0xfc [cfg80211])
[ 167.876132] [<bf17444c>] (cfg80211_new_sta [cfg80211]) from [<bf281238>] (rtw_cfg80211_indicate_sta_assoc+0x74/0x90 [r8723bs])
[ 167.888942] [<bf281238>] (rtw_cfg80211_indicate_sta_assoc [r8723bs]) from [<bf23d2c8>] (rtw_stassoc_event_callback+0x1ac/0x1c4 [r8723bs])
[ 167.902825] [<bf23d2c8>] (rtw_stassoc_event_callback [r8723bs]) from [<bf247888>] (mlme_evt_hdl+0x74/0xa8 [r8723bs])
[ 167.914665] [<bf247888>] (mlme_evt_hdl [r8723bs]) from [<bf2335f0>] (rtw_cmd_thread+0x184/0x3c4 [r8723bs])
[ 167.925494] [<bf2335f0>] (rtw_cmd_thread [r8723bs]) from [<c0364aac>] (kthread+0x148/0x150)
[ 167.934828] [<c0364aac>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[ 167.942893] Exception stack(0xec1e3fb0 to 0xec1e3ff8)
[ 167.948532] 3fa0: 00000000 00000000 00000000 00000000
[ 167.957668] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 167.966803] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 167.974192] Code: 1a000003 e5963004 e3130001 1a000000 (e7f001f2)
[ 167.980997] ---[ end trace f96e3734b79ffe1a ]---')
May the upstream developers have an interest about it ?

[summers]

Yes i should mainline patches i have. I've now done the changes needed to the bluetooth code - really thats nothing more than identifying the code which the device tree should load. So you should be able to test bluetooth by issuing by hand the command:$this->bbcode_second_pass_code('', 'modprobe hci-h5') at least thats what I assume the module is called.

Hopefully get a chance this friday to do the patches - which seems a bit of an art form - i need to read up on the commands each time I do it ...

Even if I get it done - guess it won't go mainline before 4.21.

Oh yes - I'll probably have to do a series of device tree blobs for you - to check the minimal configuration needed to enable wi-fi. Mainline didn't like the code splurge that rockchip did for wi-fi ... so I'll need careful justification of each change needed.

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'O')h yes - I'll probably have to do a series of device tree blobs for you

[TheSaint]

I've tried with latest kernel, but still not function the eMMC recognition, with rk3288-tinker.dtb. So everything gets up to the initrd but when trying to chroot onto the partition, then it isn't there.

[TheSaint]

Updated the kernel ,Linux alarm 4.19.10-1-ARCH, but no luck. The stock dtb doesn't find the root partition.
Then I tried the rk3288-tinker.dtb and I boots the latest alarm kernel . I don't see bluetooth yet

[summers]

Oh yes, should say I submitted the patch to kernel to enable the device tree to reference the bluetooth on the TB(S):

https://www.spinics.net/lists/linux-bluetooth/msg78457.html

Now we won't really be able to test this until it goes mainline, so the patch to the device tree to enable bluetooth I may leave until the wi-fi patch goes in. I'll work on that next (well I may stack up the bluetooth one, and just not send it in).

The wifi device tree for TB(S) that asus submitted was a mess, it modified huge bits of the device tree, and in ways that the official kernel doesn't like. So I'm going to have to have a string of possible device trees to test, just to see what works. Getting the wifi through to mainline will be hard, as there is a story to tell - and we'll need to be sure we known the story.

Oh yes - havn't checked, but the 4.20 kernel which just came out should have the TBS device tree in it - that was expected to be the first mainline release ... and just enough to boot from the eMMC or sD ...

[TheSaint]

You're an angel
Sorry, I loose my faith on the TBS in such way that I started to procrastinate the project. Even try to work with the proposes linaro, it became rather a hard job to slim it down for a server use.
I'll get back and try out the latest kernel.

For the bluetooth, the debian derived have the clause BTCOEX to make that working. But I suspect there's a patch on the realtek module.
Anyway I give a thumb up to the Armbian staff because they got some solutions for the TB(S), which it means to find a possible cooperation for this mere SBC.

[summers]

Starting to look at the TBS device tree again, with aim of getting the wifi to work.

On the sd card you mentioned you needed "broken-cd" to stop contant errors when there is no sd card. Just checking mainline, it has "card-detect-delay = <200>;" - so wonder if that is enough to stop the errors?

Have you tried the rk3288-tinker-s.dtb from the 4.20 kernel, and if so did it still have the sd card errors?

Just trying to work out if I have to mainline the "broken-cd" code ...