Device-tree improvements

$this->bbcode_second_pass_quote('summers', 'A')SUS just pushed their debian distribution with patches.

[summers]

Had some feedback from Heiko on the wi-fi - will need to spin at least one or two iterations to get it into mainline. problem is asus have done something that worked in their patch, but it isn't done in a linux kernel way. Converting to a linux kernel way will be a bit of effort ...

[summers]

Argh https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btrtl.c doesn't "set static const struct of_device_id" which is needed for device tree .compatible; which I think means that realtek blue tooth can't be specified in the device tree. What a mess ...

OK - says that to get bluetooth working will need a kernel code change. So we can't test that with just a device tree blob. What does the debian kernel do? You should be able to see by looking in:
$this->bbcode_second_pass_code('', '/sys/bus/platform/devices/ff180000.serial')
There should be a tree below there that contains bluetooth ...

So what are your thoughts on just trying to mainline wi-fi first, then do bluetooth later?

[TheSaint]

It's no problem at all.
From my side I just settle to live with that flaws. My wish is about to support the community and give the benefit to use ALarm also with TB(S). Therefore, for any needed test I'm keen to give my best.
Honestly speaking I could be happy even with a debian installation that has the same minimalist number of packages, but it's hard to find it.

I'd ask you whether you can get me the latest DTB to try. Beside that, I don't know about the u-boot case, what should be the right one ?
For my installation I still use the one with Armbian patches. But I think there might be a mainlined u-boot with the proper arrangements or perhaps to try what is given as a default.

[summers]

Well new dtb will be a bit in coming - now we have a system that works, I'm just trying to mainline in a way that fits in with mainline. So really just refactoring in a mainline way, which is actually good - mainline code has to be clean, and much of the asus code isn't clean. Thats why I couldn't get wi-fi into the kernel in that past - the asus code was a hack that isn't allowed mainline.

So how mainline is going, is to take bluetooth as hanging of a serial bus, and probably wifi hanging of a sdio bus. This makes sense as its how TBS is wrired. Problem is that serial bus is only something like a year old, and changes not made to realtek bluetooth. sdio bus I'm not sure yet exists ...

So it does make me wonder how ASUS original kernel came up, actually their code github - so I should browse.

Anyway getting things in mainline property, and its going to have to be patches into several different lists. Its probably too late for 4.20; so looking like 4.21 at the earliest. Testing will be a mess, you'll need a modular kernel - and I'll have to give some new modules.

Oh yes uboot is a sideline. as long as it can boot (e.g. access eMMC and do device trees) then we shouldn't be sensitive to it. TBS should migrate to mainline uboot on its own, IIRC uboot occasionally rebases its device trees on the kernel. next time it does this it should create a TBS environment. Now we could prod uboot people to make the change - but I'm happy for it to take its own course ...

And checked the debian kernel - it hasn't patck the realtek blue tooth. So I don't see how they could bring up blue tooth in TBS debian. Have you ever seen bluetooth working?

https://github.com/TinkerBoard/debian_kernel/blob/develop/drivers/bluetooth/btrtl.c

[TheSaint]

I have new report. It seems to work normally
In my tinkering I thought that Armbian using the same boot.scr to boot the TB. So I tried to change the rootfs with ALarm. The first trial failed, because of using the rk3288-miniarm.dtb.
So I prepared a new boot.scr as follow$this->bbcode_second_pass_code('', '# After modifying, run ./mkscr

setenv rootcmd "LABEL=TB-MM-root"
setenv usbqrk "0x2537:0x1066:u,0x2537:0x1068:u"
setenv fdtfile rk3288-tinkerS.dtb
setenv bootargs "console=ttyS2,115200n8 root=${rootcmd} usb-storage.quirks=${usbqrk} rw rootwait"

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtb/${fdtfile}; then
fdt addr ${fdt_addr_r}
fdt resize
fdt set /dwmmc@ff0c0000 broken-cd
fdt set /usb@ff500000 no-relinquish-port
if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
bootz ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi')
I took the u-boot from Armbian_5.59_Tinkerboard_Debian_stretch_next_4.14.67.7z and I change the script. Now I see the USB is working when plugging a device and the SD card absence is not flooding the dmseg.$this->bbcode_second_pass_code('', '$ dmesg |tail
[ 187.430677] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 187.444806] sd 0:0:0:0: [sda] Write Protect is off
[ 187.450173] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[ 187.450539] sd 0:0:0:0: [sda] No Caching mode page found
[ 187.456474] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 187.716925] sda: sda1
[ 187.723158] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 228.321014] usb 1-1.4: USB disconnect, device number 4
[ 904.615644] audit: type=1130 audit(1539546586.809:39): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 904.637626] audit: type=1131 audit(1539546586.809:40): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'')
A bit of audit nagging
So, maybe adding the USB quirks, and/or the other parameters on the boot.scr is making the system running. I will try to use the wifi as access point, I feel that it may not go.

[summers]

I suspect it may be the $this->bbcode_second_pass_code('', 'fdt set /dwmmc@ff0c0000 broken-cd') which is helping, before when you tried this you have the no space error, which probably means it wasn't applied. Now you have an $this->bbcode_second_pass_code('', 'fdt resize'), which help much of the time, but not always. So better is $this->bbcode_second_pass_code('', 'fdt resize 4096
fdt set /dwmmc@ff0c0000 broken-cd
fdt resize')
Anyway try removing just the $this->bbcode_second_pass_code('', 'fdt set /dwmmc@ff0c0000 broken-cd') - and if the errors come back again, then we know thats the problem. Then we can fix the device tree upstream.

Oh yes, can you check what bluetooth driver you are using. Its either btrtl or hci_h5, or maybe both. I'm going to need to do patches to that, think I've found a way forward with the bluetooth community, but should check.

[TheSaint]

I think there was an oversight to write the new statements. First the needed resizing and the third there was a typo which I haven't noted. Sorry about the misleading.
$this->bbcode_second_pass_quote('summers', 'A')nyway try removing just the$this->bbcode_second_pass_code('', 'fdt set /dwmmc@ff0c0000 broken-cd')

[summers]

Great. The sd card patch, I'll add to my next patch I push to mainline, with the wifi/bluetooth.

Having looked at the kernel code for bluetooth, I'm not all that surprised that it didn't look like coming up. It should be hanging off uart0, but the miniarm device tree doesn't make this explicit. We should be able to improve that with several patches, that I now know how tom formulate; still a few days of research though, as I'll try fix *all* realtek uart bluetooth devices in one go.

Take me through what you did with usb, e.g.
$this->bbcode_second_pass_code('', 'setenv usbqrk "0x2537:0x1066:u,0x2537:0x1068:u"
setenv bootargs "console=ttyS2,115200n8 root=${rootcmd} usb-storage.quirks=${usbqrk} rw rootwait"
fdt set /usb@ff500000 no-relinquish-port')

What is this doing? How is it doing it? the usbqrk looks like a hack - so need to understand what its doing, and if that needs a patch, or is best as a hack.

[TheSaint]

I found this quirk referred on the Armbian boot.scr . I just wanted to try if that is doing any change.
So I think I should try without and compare whether it gives anything different.

One more thing, the Armbian staff has implemented to use a second file which is imported via env import. I'd say that is pretty useful so is possible to vary certain parameters without the need to recompile boot.scr
I think that might be useful during testing, so for production is not a good thing to allow script import.

About bluetooth, you might give me some request and direction to find the data you may need.
Armbian is starting with rk3288-minarm and the bluetooth is there. But when I tried to convert it to dts the program spit out several warning/error on the way that is made.

Regarding the USB thingy, I didn't see relevant changes. Plugging USB devices is working even without those statements. But in deep I don't have any idea.