Device-tree improvements

[summers]

This one should load - I hope, wether it works or not not know. You'll need to use the dtb that I sent last ...

http://davidjohnsummers.uk/hci_uart.ko.gz

[TheSaint]

I'm sorry $this->bbcode_second_pass_code('', '$ sudo modprobe hci_uart
modprobe: ERROR: could not insert 'hci_uart': Exec format error

$ dmesg |grep -i *hci_+
<empty>
')

[summers]

Very strange, I made that one with "make modules_install" on an armv7 machine, then copied it out - so everything done the usual way.

All I can guess is when ftping to my web site, it wasn't in binary mode and created errors - I'll check that when I go home.

Still haven't done the revised patch for the sd card, alas haven't had time. Its the same solution as armbian, and ARM like it; so it should get accepted - but looking at the current patches going out, may not be until linux 5.2 ...

[summers]

checked if it had uploaded ok - and its the same online as here - so no idea what is going wrong!

[TheSaint]

Don't go out of your comfort area
You might give me the instructions about compiling that module, then I'll find out a while to compile it on my own.

[summers]

Apol for the delay - work finishes early on a friday, so when I got home early worked on the revised sd card slot patch, and got that submitted.

The looked into Vasily patch for Bluetooth and compared with Stefan. Stefan has the basis of Vasily, but is far simpler than Vasily. Vasily loads firmware that is device dependent. That this may be needed for bluetooth is a hassle, so need to do some checking on what firmware is available. This did leave me wondering the best direction for bluetooth patches, which to test, which to push for inclusion in the kernel.

I still kind like Stefans patch: https://archlinuxarm.org/forum/viewtopic.php?f=44&t=13064&start=140#p60592 and that was what I was applying - all be it I added it by hand to my 4.20 series, as that had already been hacked. So still think it would be good to check Stefans, yes it may well not work without the firmware - but if it does work its far easier.

So what does it take, well download the latest kernel - think thats a 4.20 series, but 5.0 can only be a few days out. Apply stefans patch, either automatically or by hand, depending on whats needed. Take /proc/config.gz, copy into the kenrel, uncompress - then move to .config.

Then make menuconfig - and probably set the machine type to as close to yours as possible, certainly rockchip, but maybe rk3288.

Then build the kernel, first time for me on a beagle, take over 24 hours. Once it done, subsequent compiles are quicker. Then taking the hci_uart.ko and using, or just booting the whole kernel.

To be honest, its a slow process. I know I can just leave it going on my pocket beagle, which is up 24/7 hanging off my nas. Some thinks are quick "make dtbs" will do the device tree, which for just a single architecture is quick. So its a tad painful, but actually good to learn - give more exposure to the kernel, and how it fits in a working OS.

Eventually though leads to bitter old men like Stefan and I, we know a fair bit more, but a whole lot less than the people who designed the whole set up, but also give great respect to those that actually do get code into the kernel.

Oh yes - for the hci_uart.ko.gz that you download, may be worth trying:
$this->bbcode_second_pass_code('', 'md5sum hci_uart.ko.gz
f2ab8e30c14812ae4f3ef4e49514ec14 hci_uart.ko.gz')
So just to check if that was preserved.

Anyway I need to read more of Vasily patch, and try and understand it ...

[summers]

Ok, this will sound silly. But if you have a working original debian set up for TBS, can you see if you have any rtl8723bs_config*.bin files in /lib/firware. On my beagle board I have:
$this->bbcode_second_pass_code('', '/lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
/lib/firmware/rtl_bt/rtl8723bs_fw.bin
/lib/firmware/rtlwifi/rtl8723bs_ap_wowlan.bin
/lib/firmware/rtlwifi/rtl8723bs_bt.bin
/lib/firmware/rtlwifi/rtl8723bs_nic.bin
/lib/firmware/rtlwifi/rtl8723bs_wowlan.bin')
Sounds like there is meant to be a file for each machine ...

As it stands I think the bluetooth machine id needs to be OBDA8723 - just try to find what that means ...

[TheSaint]

The module checksum is $this->bbcode_second_pass_code('', '$ md5sum hci_uart.ko.gz
f2ab8e30c14812ae4f3ef4e49514ec14 hci_uart.ko.gz')That looks same as you posted.
The linaro (aka tinkerOS) has this typology$this->bbcode_second_pass_code('', '$ ls /mnt/lib/firmware/rt*
/mnt/lib/firmware/rtlbt:
rtl8723b_config rtl8723b_fw

/mnt/lib/firmware/rtlwifi:
rtl8814aufw.bin')
The module compilation it will take place soon, I'm bit busy, so I don't have the figure when I'll be free to do that.

EDIT
Facing some difficulties to compile without the correct configuration, or that I should use. Indeed I don't know which should be the correct one. I got the one from /proc, but it seems non fitting to the purposed kernel 4.20.11 .

[summers]

Looks like you have both bluetooth firmware blobs, so yes its suggesting this is needed. Author of the other bluetooth patch says we need a blob for every board; but the blobs are binary - so don't think they can be created. The only blobs that seem commonly available are the ones in /lib/firmware/rtl_bt - so the OBDA8723 one. Would be interesting to know if its different from yours. This should do it:
$this->bbcode_second_pass_code('', '$ ls -l /lib/firmware/rtl_bt/rtl8723*
-rw-r--r-- 1 root root 24548 Jan 26 17:03 /lib/firmware/rtl_bt/rtl8723a_fw.bin
-rw-r--r-- 1 root root 45048 Jan 26 17:03 /lib/firmware/rtl_bt/rtl8723b_fw.bin
-rw-r--r-- 1 root root 64 Jan 26 17:03 /lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
-rw-r--r-- 1 root root 52116 Jan 26 17:03 /lib/firmware/rtl_bt/rtl8723bs_fw.bin
-rw-r--r-- 1 root root 10 Jan 26 17:03 /lib/firmware/rtl_bt/rtl8723d_config.bin
-rw-r--r-- 1 root root 47028 Jan 26 17:03 /lib/firmware/rtl_bt/rtl8723d_fw.bin
$ md5sum /lib/firmware/rtl_bt/rtl8723*
8aaacb8316460497459b0db4abd3d565 /lib/firmware/rtl_bt/rtl8723a_fw.bin
b3363f17ba07a53bfd891fe1b4072e0b /lib/firmware/rtl_bt/rtl8723b_fw.bin
57b61c775a51f7a4596950ded7d2d4c0 /lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
521d95f75577c49eae09b00704c3823d /lib/firmware/rtl_bt/rtl8723bs_fw.bin
6551d1f5c5a9c4ce7ab755d58576e0b0 /lib/firmware/rtl_bt/rtl8723d_config.bin
c5eb81a9005ddfc2a5ffe8996c4a5a24 /lib/firmware/rtl_bt/rtl8723d_fw.bin
')
There is a different one for pine64 here: https://github.com/anarsoul/rtl8723bt-firmware

And here is the commit for the OBDA8723 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/rtl_bt/rtl8723bs_config-OBDA8723.bin?id=e6b9001e91110c654573b8f8e2db6155d10d3b57

Means that bluetooth is getting vague. I'll check what armbian does ... armbian enables the serial interface - but doesn't bring up the bluetooth side of things, so I don't think has anything to say on firmware.

With compile, did you copy "config" to ".config" after uncompromising? Think you are using an generic armv7 kernel, so it will have a lot defined - hence why a good idea to back off the "System Type" to "Rockchip RK2928 and RK3xxx SOCs" and check under "Net-->bluetooth-->drivers" that "Three-wire UART (H5) protocol support" is selected, and below it appears "Realtek protocol support" which is selected. This latter only appears when the patch has been applied ...

If the .config is really complaining "make oldconfig" usually solves ...

[summers]

Oh yes what I should have also said, instead of moving "config" to ".config" you can also after $this->bbcode_second_pass_code('', 'make menuconfig') you can load the "config" file, use "tab" to move around ...