Device-tree improvements

This is for any ARMv7 device that we do not officially support.

Re: Device-tree improvements

Postby TheSaint » Mon Oct 08, 2018 5:49 am

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

Exactly !!
They just see a business figure to clone a raspberry. But the experience cannot copy :)

$this->bbcode_second_pass_quote('summers', 'T')his is a pity, as the basic TB(S) machine we are getting close to it just running the plain vanilla arm arch, and have most things basically working, with just a few rough edges.


Yes, the kernel is good even the latest one.
It feels like we got a little audience. Perhaps there are no many users that will look to this perspective and if any, then (s)he drop the idea very quickly and settle down with the available choices.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Mon Oct 08, 2018 10:30 am

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
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby summers » Thu Oct 11, 2018 9:41 am

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?
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Thu Oct 11, 2018 10:58 am

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.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Fri Oct 12, 2018 9:08 am

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
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Sun Oct 14, 2018 7:55 pm

I have new report. It seems to work normally :D
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.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Mon Oct 15, 2018 6:42 pm

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.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Tue Oct 16, 2018 9:01 am

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')

No, no, that's the cure :). Without the statement it's coming the joggling messages unstoppable.
About bluetooth, nothing is coming up during boot time$this->bbcode_second_pass_code('', 'dmesg |grep -i blue
...promtp>$

$ ls /proc/device-tree/wireless-bluetooth/
BT,reset_gpio BT,wake_host_irq name pinctrl-1 status
BT,wake_gpio compatible pinctrl-0 pinctrl-names uart_rts_gpios

$ find /sys -iname *bluet*
find: '/sys/kernel/debug': Permission denied
/sys/devices/platform/wireless-bluetooth
/sys/firmware/devicetree/base/wireless-bluetooth
/sys/firmware/devicetree/base/pinctrl/wireless-bluetooth
find: '/sys/fs/bpf': Permission denied
/sys/bus/platform/devices/wireless-bluetooth')
I've try to load the module, but it has no functions.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am
Top

Re: Device-tree improvements

Postby summers » Tue Oct 16, 2018 12:04 pm

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.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Tue Oct 16, 2018 5:12 pm

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.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

PreviousNext

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 6 guests