Device-tree improvements

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

Re: Device-tree improvements

Postby TheSaint » Thu Aug 22, 2019 7:04 am

A kernel crash
$this->bbcode_second_pass_code('', ' ------------[ cut here ]------------
[ 465.404724] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:39 i2c_transfer+0xe8/0xf4
[ 465.413567] No atomic I2C transfer handler for 'i2c-0'
[ 465.419301] Modules linked in: bnep bluetooth ecdh_generic ecc 8021q garp mrp stp llc joydev snd_soc_hdmi_codec realtek dw_hdmi_cec dw_hdmi_i2s_audio snd_soc_simple_card snd_soc_simple_card_utils evdev snd_soc_rockchip_i2s snd_soc_rockchip_pcm snd_soc_core ac97_bus snd_pcm_dmaengine panfrost rockchip_rga v4l2_mem2mem videobuf2_dma_sg videobuf2_memops gpu_sched videobuf2_v4l2 videobuf2_common dw_wdt rk_crypto r8723bs(C) pwm_rockchip snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq_device snd_pcm snd_timer cfg80211 rfkill dwmac_rk stmmac_platform rockchipdrm stmmac dw_mipi_dsi analogix_dp rockchip_saradc dw_hdmi uio_pdrv_genirq uio sch_fq_codel crypto_user ip_tables x_tables
[ 465.487046] CPU: 0 PID: 1 Comm: shutdown Tainted: G C 5.2.9-3-ARCH #1
[ 465.495694] Hardware name: Rockchip (Device Tree)
[ 465.500954] [<c0311340>] (unwind_backtrace) from [<c030bf60>] (show_stack+0x10/0x14)
[ 465.509609] [<c030bf60>] (show_stack) from [<c0f275ac>] (dump_stack+0xa4/0xb8)
[ 465.517678] [<c0f275ac>] (dump_stack) from [<c034680c>] (__warn+0xd4/0xf0)
[ 465.525360] [<c034680c>] (__warn) from [<c034638c>] (warn_slowpath_fmt+0x48/0x6c)
[ 465.533721] [<c034638c>] (warn_slowpath_fmt) from [<c0c4d0c4>] (i2c_transfer+0xe8/0xf4)
[ 465.542666] [<c0c4d0c4>] (i2c_transfer) from [<c0a83584>] (regmap_i2c_read+0x58/0x88)
[ 465.551418] [<c0a83584>] (regmap_i2c_read) from [<c0a7f834>] (_regmap_raw_read+0xec/0x148)
[ 465.560651] [<c0a7f834>] (_regmap_raw_read) from [<c0a7f8c8>] (_regmap_bus_read+0x38/0x60)
[ 465.569885] [<c0a7f8c8>] (_regmap_bus_read) from [<c0a7ea1c>] (_regmap_read+0x60/0xb8)
[ 465.578730] [<c0a7ea1c>] (_regmap_read) from [<c0a7ee7c>] (_regmap_update_bits+0xb0/0xec)
[ 465.587867] [<c0a7ee7c>] (_regmap_update_bits) from [<c0a7fe14>] (regmap_update_bits_base+0x4c/0x70)
[ 465.598073] [<c0a7fe14>] (regmap_update_bits_base) from [<c0a9e024>] (rk808_device_shutdown+0x44/0x70)
[ 465.608474] [<c0a9e024>] (rk808_device_shutdown) from [<c0368508>] (sys_reboot+0x158/0x218)
[ 465.617806] [<c0368508>] (sys_reboot) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
[ 465.626357] Exception stack(0xea06ffa8 to 0xea06fff0)
[ 465.631996] ffa0: 00000000 00000000 fee1dead 28121969 4321fedc a12dc500
[ 465.641123] ffc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
[ 465.650257] ffe0: 004cde40 bec20cc4 004b7d74 b6bf1420
[ 465.655896] ---[ end trace eca2ec50d2cd0b31 ]---
')
It might be because I've tried to start the bluetooth.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Thu Aug 22, 2019 10:38 am

Which kernel driver were you using. Its meant to be hci_h5 - but need to make sure that the kernel knows which UART the interface is on.

I didn't think that the bluetooth used i2c, although the wifi/bluetooth realtek chip set probably has an i2c interface.

Should be able to look at the device tree and see what i2c-0 is tied to - that should help identify what is causing the problem ...

I2c0 seems to be connected to the regulator chip - rk808 ; it does all the voltages etc. Seems strange that it went down ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Fri Aug 23, 2019 6:46 am

Kernel
$this->bbcode_second_pass_code('', 'Linux alarm 5.2.9-3-ARCH #1 SMP PREEMPT Wed Aug 21 19:15:47 UTC 2019 armv7l GNU/Linux
$ ll /boot/dtbs/
total 112
-rw-r--r-- 1 root root 53425 Aug 22 03:14 rk3288-tinker-s.dtb ### stock DTB
-rw-r--r-- 1 root root 53249 Aug 22 03:14 rk3288-tinker.dtb')
I don't think the RT8723BS is connected via i2C, as the Armbian fellows have patched to interface to UART0. Even though is possible to configure and use as I2C port.
Anyways, that is caused by my attempt to activate the bluetooth interface. I have the bluetooth.service enabled.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby TheSaint » Mon Nov 18, 2019 3:53 am

I took out from the drawer my TBS, and give a brand new try.
Since last experimenting I got WiFi improved and stabile.

Unfortunately I can't say anything about bluetooth, which has some year to come, or none.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Mon Nov 18, 2019 10:37 am

Trying to remember where we left it.

On the device tree submitted to mainline, we had enabled wi-fi - it was carefully reviewed, and so it should work perfectly. if it doesn't work, then need to dig into the fault, and submit patches.

Bluetooth was connected via uart0; so in a modern way to use this is SerDev. Now the hci_h5 driver that your machine needs for bluetooth, when last looked had dan't been converted to SerDev usage. When that change is made, the patch I gave a page or two ago, should be fine for enabling bluetooth in the kernel. What you attach above, you'll need to look into.

From what I recall we left it all fairly stable on TBS. So although not technically supported by ArchArm, it should run without problems, so a bit like my pocket beagle that also isn't supported.

If I get time I'll check the hci_h5 driver in mainline kernel (its the 3 wire bluetooth driver) and see what changes have been made. It shouldn't be hard to convert to SerDev, but I'm not an expert there.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Tue Nov 19, 2019 1:38 pm

Well the Wifi was working fine since a bit long. But I found some problem on the 80211 matter that crashed several time. I wrote it somewhere in this discussion. Also other reported such failure for a different hardware, lately. That's over now. I tested and i don't see crashes any more.

Anyways, It seems that your efforts are gone to the right places and I might say that the dtb are very similar. The access to the bluetooth is likely the way to be connected to the UART0, as armbian fellow used to patch.

So I'm very glad for your works about the TB.
Unfortunately it seems that has gotten out of interest. The RPi 4 challenges the TB performances very close and also the price is close too (for the 2 Gb RAM version). The only difference is what the producer gives to know to the developers. Even the tinkerboarding.co.uk got a bit of vacuum lately :) .
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Tue Nov 19, 2019 2:52 pm

The armbian patch is similar to what was used by asus on the default OS.

Unfortunately its patching the device tree in a none standard way (by adding bluetooth-platdata) and so won't be accepted in mainline. Guess thats the hassle of mainline ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Thu Nov 21, 2019 5:49 am

So I have the smallest option to adopt the patch given in a non standard way or nothing.
I might agree with the mainline directions, simply they will lead to nothing usable. So the only disrupt is caused for a hardware only, I think and I have to get it as is.

For such design, can you give me a little help to modify the dtb and we'll get it tested just for my own use, or whoever will accept it as is.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Thu Nov 21, 2019 10:33 am

I may take a copy of the linux bluetooth directory, when I go away for Christmas, and see if I can have a go at rewriting the 3 wire driver as a SerDev driver. Hassle is understanding enough about bluetooth, 3 wire protocol, and serdev, and which code has responsibility for each bit. Conceptually should be simple, RX, and TX are done by the uart, all other wires to the chip I guess will need to be handled by the driver. Then anything protocol probably handled by the driver.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Fri Nov 22, 2019 5:19 pm

Oh no, I thought it was simpler, don't get stressed, please.
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 4 guests