RK3328 Kernel

[Myy]

9 hours ago, TonyMac32 said:

wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.

 

Yay ! ＼（・ヮ・）／

 

Well, that's one more integrated element supported.

 

So, besides the VCodec driver, what Tinkerboards' drivers are still completely missing ? Bluetooth I guess ?

[TonyMac32]

Yes, I've had trouble with Bluetooth, although to be honest it hasn't been at the top of the list.  There is also the camera/display ports and the reboot bug. 

[Tido]

Reboot;  For Kernel 4.4.x you reported:  The Miqi must not use vmmc or vqmmc supplies, or else it would also be affected.  The shutdown sequence turns the SD card off completely before reboot, and fails to reset to 3.3 volts from 1.8 (for high-speed cards).

 

Have you had a look if the cause is the same?

 

[TonyMac32]

There has been some shuffling of code, but as the symptoms are identical and, from what I can tell, nothing has really changed in the actual shutdown process, I would assume so.  Given the hackish nature of the 4.4 fix, however (even the Rockchip repo has it labeled "HACK"), I haven't probed too deeply into it, I'm holding out hope that 4.12 will include an actual fix for this eventually. 

[Hidenori Nagao]

Hello Armbian developers,

 

I' using the latest stable release 4.470 kernel version. Having issue for "autofs" package installation. The installation fails because of daemon launch ended up with error return. Manual launch gives me followings. Any idea what's going on? Is this because of lacking "autofs4" kernel module? If yes, any chance to include it in?

 

root@ARMBIAN:/etc/init.d# /etc/init.d/autofs start
[....] Starting autofs (via systemctl): autofs.serviceJob for autofs.service failed because the control process exited with error code. See "systemctl status autofs.service" and "journalctl -xe" for details.
 failed!
 

Many thanks for your effort of Tinker Board developments. I like Armbian port feel much better than TinkerOS.

 

Hidenori 

[TonyMac32]

I'm afraid I can't speak to this issue, although I have tried installing autofs on 4.4 and I got the error you did.  I then tried it on 4.12, and had no errors.  If you don't have a specific requirement for the 4.4 kernel, I'd recommend trying the 4.12.

[Hidenori Nagao]

TonyMac32,

 

Thanks for your check and response. In general, it's okay for me to move to 4.12 except the issue "reboot" you guys are discussing here. The reboot issue is only the reason I picked legacy kernel version for my setup. A failure of reboot is so painful for software package installation and remote maintenance. I wish either on of the issues autofs on 4.4 or reboot on 4.12 (even though it is hack) will be fixed. But many thanks for your efforts supporting this ASUS board.

 

Hidenori

[sghazagh]

TonyMac32/All,

You answered my question in Tinker Board official GITHUB repository , thank you first of all,  but I still stuck in solution you have provided.

 

Ok,

Assume I want to use Armbian Kernel 4.12. You mentioned it has lots of improvement and that's good now because you also added the WIFI as well.

So I got all Armbian stuff installed and I have compiled the Kernel as well.

But it gave me DEB packages. That's fine too... But the way Armbian works is different than official setup (extlinux and extlinux.conf file). I even installed the u-boot package generated by Armbian Kernel Compile and that even couldn't load the Board!

So, then I tried to grab the zImage and DTB file from compiled kernel folder, this does not boot my Tinker Board either!

 

In short: How can I use Armbian Kernels (zImage), DTB and Modules with for instance official Debian image 1.8?!

 

 

 

[sghazagh]

Hello all,

I have a question about Tinker Board Bluetooth, what I hope you can help me!

 

I have used official Tinker Board Source to compile the Kernel and it is running ok.

Except in my rootfs , which I have created from Ubuntu debootstrap, when I list devices by "rflink list", it only shows phy0 Wireless Drive however, in main Debian 1.8 rootfs, it lists phy0 and also chi0 which is Bluetooth device.

Therefore the Bluetooth device does not recognized and does not work on my rootfs!

 

My question is that, is there any thing I have to configure in rootfs to be able to recognize the device?

I checked UDEV in both rootfs and there is nothing really related to Bluetooth device specifically!

I assumed the role of device tree is to know and bring up the devices, am I correct?

 

Can you guys who are familiar with Hardware please put me in the track and assist me making the Bluetooth working on my rootfs?

 

If you need to get a copy of my Tinker Board Image to have a look, please download it from here:  http://www.elar-systems.com/website/index.php/entertainment/member-area/download/2-downloads/18-asus-tinkerboard-lubuntu16-04-2-lts-elar-systems-sd

 

I really do appreciate your help...

 

P.S: in above image, I realized that the Firmware have not synced properly. Therefore, after burning the image I manually deleted all the firmware and replicated the firmware from Debian 1.8 image. You also need to do that too if you really got time to dig into the problem!
 

[Igor]

9 hours ago, sghazagh said:

But the way Armbian works is different than official setup

Our root system is simple to maintain, matured, clean - in any way better than official creations. I am not sure anyone wants to analyse, how Asus glue their images together. They failed on board design and generally all board makers images proved to be bad quality. We only peek for some special thing, but here I don't see any reason.

 

We just started to add wireless and Bluetooth support and I am not sure it's already fully done. ASUS still haven't deliver board samples, which means not many people can work on this.

 

6 hours ago, sghazagh said:

in above image

You have to contact image creators (Asus or whoever). There is a reason why we don't alter stock Debian / Ubuntu much, since there is plenty of complexity already and time is wasted on irrelevant issues.

[tkaiser]

9 hours ago, sghazagh said:

How can I use Armbian Kernels (zImage), DTB and Modules with for instance official Debian image 1.8?!

You can't and that's fine since no one needs ELAR branded OS images where people manually fiddled around. Armbian's approach is different (creating images ALWAYS from scratch and therefore 'documenting' every necessary step or let's better say every single step done in form of scripts and templates in the build system).

 

@Igorcompare the situation with DietPi here, it's essentially the same but this time the results are 'ELAR images' or something like that.

[sghazagh]

On 06/06/2017 at 5:47 PM, tkaiser said:

You can't and that's fine since no one needs ELAR branded OS images where people manually fiddled around. Armbian's approach is different (creating images ALWAYS from scratch and therefore 'documenting' every necessary step or let's better say every single step done in form of scripts and templates in the build system).

 

@Igorcompare the situation with DietPi here, it's essentially the same but this time the results are 'ELAR images' or something like that.

In the morning, I was very upset from you and wrote something that was not look good to others!
Tido, who is a very nice guy asked me to edit the post and because I do respect him, I completely remove my text.

Hereby, I do ask you to never reply to any of my posts and leave me alone. You already have upset me few times, do not want to go through that anymore...

Thanks

 

[sghazagh]

14 hours ago, Igor said:

Our root system is simple to maintain, matured, clean - in any way better than official creations. I am not sure anyone wants to analyse, how Asus glue their images together. They failed on board design and generally all board makers images proved to be bad quality. We only peek for some special thing, but here I don't see any reason.

 

We just started to add wireless and Bluetooth support and I am not sure it's already fully done. ASUS still haven't deliver board samples, which means not many people can work on this.

 

You have to contact image creators (Asus or whoever). There is a reason why we don't alter stock Debian / Ubuntu much, since there is plenty of complexity already and time is wasted on irrelevant issues.

 

Thank you Igor. I appreciate that.

I try to understand the Armbian build first then hope I can adjust it for my use.

 

Thanks again

[Brian Retford]

The latest image is looking really good. Curious why y'all went with the rp16 mali drivers -- hypothetically, if you stick with rp13 than you can get opencl / opengl to work: https://github.com/rockchip-linux/libmali . I'm definitely open to trying to make that happen myself -- is building an armbian image with an older midgard driver simple enough? Haven't tried yet.

[tkaiser]

12 hours ago, sghazagh said:

Hereby, I do ask you to never reply to any of my posts and leave me alone.

 

I think all the relevant persons who might have wasted their time supporting you in providing hand-crafted OS images for whatever reasons (to promote your company or such stuff?) in the meantime already got the idea what to expect  

[Myy]

7 hours ago, Brian Retford said:

The latest image is looking really good. Curious why y'all went with the rp16 mali drivers -- hypothetically, if you stick with rp13 than you can get opencl / opengl to work: https://github.com/rockchip-linux/libmali . I'm definitely open to trying to make that happen myself -- is building an armbian image with an older midgard driver simple enough? Haven't tried yet.

 

Well, I went with the r17p0 drivers with my kernels and the user-space binary drivers work fine, whether it's the rockchip libmali drivers, or the one provided by ARM for Firefly systems (mostly used for fbdev).

 

The Mali user-space and kernel-space drivers are not directly correlated. They're both needed (although I wonder if it's possible to access the GPU acceleration directly through the kernel interface). However, the user-space binary drivers will work as long as the kernel-space driver version is equal or superior. I guess there's a dumb check like this, in the user space binary drivers.

 

uint_fast8_t is_kernel_version_valid() { return user_version <= kernel_version; }

 

Also, recent versions of the Mali kernel drivers tend to support more 'recent' kernels (4.9 maximum, IIRC), while older versions might have to be patched and adapted to 4.7, 4.8 and 4.9 changes.

 

That said :

If you encounter issues with Rockchip r13p0 user-space binary drivers and kernel r16p0 drivers, I could provide some help.

If you want to try integrating the r13p0 kernel drivers, you could get them here :

https://developer.arm.com/products/software/mali-drivers/midgard-kernel

And try playing with my script here :

https://github.com/Miouyouyou/MyyQi/blob/master/GetPatchAndCompileKernel.sh

Or you could also try to adapt phusson OOT Mali modules drivers here :

https://github.com/phhusson/rockchip_forwardports

[Brian Retford]

Hmmm. I had the rp13 user space and the rp16 kernel space and running clinfo / any OCL programs complains about some DKK error. I'll dig into it more though. ARM *implies* a tight correlation between user space and kernel space, but that seems extremely difficult to manage if so.  Thanks for the links, I'll poke around see what I can accomplish.

[Myy]

This error is generally due to /dev/mali0 being inaccessible. If the user-space binary driver cannot access /dev/mali0 it will print a generic error message, telling you that the kernel driver doesn't fit.

This can be due to the Mali driver not being loaded, or the current user not being able to access /dev/mali0 due to the current permissions set on the device node.

 

If you have some OpenCL code that you trust, you might want to compile and test it as root.

 

Meanwhile, I try to give a shot at a simple OpenCL example, and the ARM compute library, and both worked. Though, the examples of the Compute Library aren't very noisy and I don't understand how to use them currently.

 

Anyway, here's the results. I pasted the simple OpenCL example code in the file test.c . I used the OpenCL headers provided by the ARM Compute Library since I guess they are suited for their hardware (At least, I hope so) :

 

gamer@tachibana /tmp $ gcc -o /tmp/test /tmp/test.c -lOpenCL -I /tmp/ComputeLibrary/include
gamer@tachibana /tmp $ ./test
Platform - 1
  1.1 CL_PLATFORM_NAME: ARM Platform
  1.2 CL_PLATFORM_VENDOR: ARM
  1.3 CL_PLATFORM_VERSION: OpenCL 1.2 v1.r12p0-04rel0.c7cf4c8b39970391360f91824733eb1a
  1.4 CL_PLATFORM_PROFILE: FULL_PROFILE
  1.5 CL_PLATFORM_EXTENSIONS: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_fp64 cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_gl_sharing cl_khr_icd cl_khr_egl_event cl_khr_egl_image cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory
  Device - 1:
    CL_DEVICE_NAME: Mali-T760
    CL_DEVICE_VENDOR: ARM
    CL_DRIVER_VERSION: 1.2
    CL_DEVICE_VERSION: OpenCL 1.2 v1.r12p0-04rel0.c7cf4c8b39970391360f91824733eb1a
    CL_DEVICE_MAX_COMPUTE_UNITS: 4
gamer@tachibana /tmp $ uname -a
Linux tachibana 4.12.0-rc4-The-Twelve-MyyQi+ #1 SMP PREEMPT Mon Jun 5 14:12:21 UTC 2017 armv7l Rockchip (Device Tree) GNU/Linux

The ARM Compute Library examples gave me that :

gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ cp -r ../../src/core/CL/cl_kernels ./
gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ LD_LIBRARY_PATH=. ./cl_convolution 

./cl_convolution

Usage: ./build/cl_convolution [input_image.ppm]

No input_image provided, creating a dummy 640x480 image

Test passed
gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ ls
cl_convolution  libarm_compute_core.so        src
cl_events       libarm_compute_core-static.a  test_helpers
cl_kernels      libarm_compute.so
examples        libarm_compute-static.a
gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ LD_LIBRARY_PATH=. ./cl_events 

./cl_events

Usage: ./build/cl_events [input_image.ppm]

No input_image provided, creating a dummy 640x480 image

Test passed

Test passed... Well I guess it's okay then

 

 

[waterman480]

I am not hearing any audio over HDMI.  Any clue?.  My image is dated 5/4/17 and has the latest updates applied.

[Myy]

8 hours ago, waterman480 said:

I am not hearing any audio over HDMI.  Any clue?.  My image is dated 5/4/17 and has the latest updates applied.

 

What do lsmod and uname -a return ?

[Myy]

So I'm trying to add Bluetooth support for Tinkerboard devices and after searching for any "Bluetooth" related option in the kernel, I stumbled into CONFIG_RTLBTCOEXIST . So in addition to CONFIG_BT_HCI_UART , this option might be needed to use the BT Coexist functionalities of the Realtek 8723 BS devices.

 

However, it turns out that CONFIG_RTLBTCOEXIST cannot be enabled directly. If you search for the symbol in menuconfig , you won't see any configuration section referenced. So, in order to enable it, you need to enable its dependencies, which are :

 

CONFIG_NETDEVICES (Network device support)

CONFIG_WLAN (Wireless LAN)

CONFIG_WLAN_VENDOR_REALTEK (Realtek devices)

CONFIG_RTL_CARDS (Realtek rtlwifi family of devices)

And also one of these drivers :

CONFIG_RTL8723AE (Realtek RTL8723AE PCIe Wireless Network Adapter)

CONFIG_RTL8723BE (Realtek RTL8723BE PCIe Wireless Network Adapter)

CONFIG_RTL8192EE (Realtek RTL8192EE Wireless Network Adapter)

CONFIG_RTL8821AE (Realtek RTL8821AE/RTL8812AE Wireless Network Adapter)

Which depend on :

CONFIG_PCI (PCI support)

 

So, I've generated a configuration that integrate these requirements. If any Tinkerboarder could give it a shot and see if they, at least, get a hci0 interface, this would be great !

 

The configuration file is :

 

https://github.com/Miouyouyou/MyyQi/blob/master/boot/config-4.12.0-rc4-The-Twelve-MyyQi%2B

 

If you don't get anything, could you paste the dmesg content ?

[TonyMac32]

Hmmm, btcoexist pops up when the sdio RTL8723bs module is loaded, are you sure it needs to be separately configured?

[    6.689885] r8723bs: module is from the staging directory, the quality is unknown, you have been warned.
[    6.696989] RTL8723BS: module init start
[    6.697023] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[    6.697027] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
[    6.698894] pnetdev = ed9e1000
[    6.900133] RTL8723BS: rtw_ndev_init(wlan0)
[    6.903840] RTL8723BS: module init ret =0

 

tony@tinkerboard:~$ dmesg | grep Bluetooth
[    0.323257] Bluetooth: Core ver 2.22
[    0.323331] Bluetooth: HCI device and connection manager initialized
[    0.323350] Bluetooth: HCI socket layer initialized
[    0.323364] Bluetooth: L2CAP socket layer initialized
[    0.323415] Bluetooth: SCO socket layer initialized
[    1.496904] Bluetooth: HCI UART driver ver 2.3
[    1.496917] Bluetooth: HCI UART protocol H4 registered
[    1.496925] Bluetooth: HCI UART protocol LL registered
[    1.496933] Bluetooth: HCI UART protocol ATH3K registered
[    1.496941] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    1.497272] Bluetooth: Generic Bluetooth SDIO driver ver 0.1
[    1.568237] Bluetooth: RFCOMM socket layer initialized
[    1.568264] Bluetooth: RFCOMM ver 1.11
[    1.568282] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    1.568300] Bluetooth: HIDP socket layer initialized

I did find some pinctrl entries in the Rockchip/ASUS dts for uart0, which according to the wireless-bluetooth entry is the BT port:

 

&uart0 {
	pinctrl-names = "default";
	pinctrl-0 = <&uart0_xfer>, <&uart0_cts>;
	status = "okay";
};

I enabled the H5 3-wire and added the bluetooth-wireless entry last night to no success, missed the uart0 pinctrl stuff.

[Myy]

Well, while the RTL8723bs driver itself will tell you the reference of the Bluetooth chip, BTCoexist, I don't think that it knows how to use directly. I'm wondering if it doesn't delegate the whole management to that other driver.

 

Anyway, I thought that would worth a try, since it's related to rtlwifi drivers and seem to coincide with the dmesg output for the RTL8723bs WLAN driver. Given that everything else has been loaded, I'm wondering what else could be missing.

[TonyMac32]

Fair enough, I'm doing some headscratching, see the edit I made to my post, I'm trying something real quick before getting back to what I get paid for... 

 

I checked out the config for Tinker_OS 1.8, none of that stuff is enabled either, of course they also recoded half the rfkill subsystem...

[Myy]

Alright, I'll take a look at how Tablets kernels implement it then, if any use DTS files

[TonyMac32]

No dice on my side, but I'll try those compiled tools I linked to on your git:  https://github.com/lwfinger/rtl8723bs_bt

[Myy]

I just checked, the rtl8723bs module has an absurd number of options !

 

parm:           rtw_ips_mode:The default IPS mode (int)
parm:           rtw_usb_rxagg_mode:int
parm:           rtw_btcoex_enable:Enable BT co-existence mechanism (int)
parm:           rtw_ant_num:Antenna number setting (int)
parm:           rtw_qos_opt_enable:int
parm:           ifname:The default name to allocate for first interface (charp)
parm:           rtw_initmac:charp
parm:           rtw_channel_plan:int
parm:           rtw_chip_version:int
parm:           rtw_rfintfs:int
parm:           rtw_lbkmode:int
parm:           rtw_network_mode:int
parm:           rtw_channel:int
parm:           rtw_wmm_enable:int
parm:           rtw_vrtl_carrier_sense:int
parm:           rtw_vcs_type:int
parm:           rtw_busy_thresh:int
parm:           rtw_ht_enable:int
parm:           rtw_bw_mode:int
parm:           rtw_ampdu_enable:int
parm:           rtw_rx_stbc:int
parm:           rtw_ampdu_amsdu:int
parm:           rtw_lowrate_two_xmit:int
parm:           rtw_rf_config:int
parm:           rtw_power_mgnt:int
parm:           rtw_smart_ps:int
parm:           rtw_low_power:int
parm:           rtw_wifi_spec:int
parm:           rtw_antdiv_cfg:int
parm:           rtw_antdiv_type:int
parm:           rtw_enusbss:int
parm:           rtw_hwpdn_mode:int
parm:           rtw_hwpwrp_detect:int
parm:           rtw_hw_wps_pbc:int
parm:           rtw_max_roaming_times:The max roaming times to try (uint)
parm:           rtw_mc2u_disable:int
parm:           rtw_80211d:Enable 802.11d mechanism (int)
parm:           rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint)
parm:           rtw_hiq_filter:0:allow all, 1:allow special, 2:deny all (uint)
parm:           rtw_tx_pwr_lmt_enable:0:Disable, 1:Enable, 2: Depend on efuse (int)
parm:           rtw_tx_pwr_by_rate:0:Disable, 1:Enable, 2: Depend on efuse (int)
parm:           rtw_phy_file_path:The path of phy parameter (charp)
parm:           rtw_load_phy_file:PHY File Bit Map (int)
parm:           rtw_decrypt_phy_file:Enable Decrypt PHY File (int)

 

Playing with rtw_btcoex_enable=1 and rtw_ant_num=1 might change something, I don't know.

 

That said, Indeed, I guess that the current best bet might be hadess and Larry Finger repositories. At least, it should be easier to put some printk during the BT initialization code in order to see why the Bluetooth chip is not enabled.

Currently, the BTCoexist serial number seems to be a value read from the hardware itself, so that doesn't tell much aside that the driver could read some metadata from the chip itself.

 

I'll postpone that to this week-end.

 

 

[TonyMac32]

Well, I sifted through commits on Tinker Boards debian kernel git for Bluetooth.  I found a lot of ugly.

 

https://github.com/TinkerBoard/debian_kernel/commit/5106d9486cf1c2bad4f701611f51a526191c56ad

 

which seems to be a rollback of

 

https://github.com/TinkerBoard/debian_kernel/commit/c500f743567e5f00efea6a6797e3c689f41ea4c7

 

So that's how it happened on Tinker Board.  It appears the individual porting LibreELEC has abandoned bluetooth on the Tinker Board as well, citing "unwanted changes to kernel"  I will safely say that is not something I want to maintain moving forward, surely there's another way, but I feel like it would involve just plain writing a driver.

[plasta-blaster]

I just wanted to say that I had accidentally left my Tinker on a stress test for about 4 days in the searing summer heat!

 

I do have an over large heatsink but when I had realised it was on a stress test I looked at the temp_watch and is was down in the 50s.

 

BUT the thing I want to point out :-

 

Yes I am a idiot for forgetting about it, but I have so many boxes running stuff I have a excuse:-)

 

In many ways this accidental test has made me very happy about this board as I have several different setups on different machines including offsite servers running the same jobs as this, but over the last 2 weeks these machines have had more issues than the Tinker.

 

It have a load of cron jobs which basically run a multi-core docker job  which I have been monitoring and I have to say even thou it was running a stress test full on for so long 'it never missed a beat on the docker multi-core jobs' I was asking it to do every few hours and I received more errors from the other under stressed systems Including droplets!

 

Thanks Armbian, Rockchip and Asus!

[Kwiboo]

On 2017-06-09 at 5:20 AM, TonyMac32 said:

Well, I sifted through commits on Tinker Boards debian kernel git for Bluetooth.  I found a lot of ugly.

 

https://github.com/TinkerBoard/debian_kernel/commit/5106d9486cf1c2bad4f701611f51a526191c56ad

 

which seems to be a rollback of

 

https://github.com/TinkerBoard/debian_kernel/commit/c500f743567e5f00efea6a6797e3c689f41ea4c7

 

So that's how it happened on Tinker Board.  It appears the individual porting LibreELEC has abandoned bluetooth on the Tinker Board as well, citing "unwanted changes to kernel"  I will safely say that is not something I want to maintain moving forward, surely there's another way, but I feel like it would involve just plain writing a driver.

 

This was the exact reason why I quickly gave up on Bluetooth for LibreELEC.

 

I recently got some new hope after the driver went mainline and seeing https://github.com/LibreELEC/LibreELEC.tv/pull/1601, unsure if it will lead to anything.