Jump to content

Recommended Posts

Posted

Ah, something I've mentioned but didn't make a big deal of:  the RK808 gets hot enough to burn you under heavy loads.  Put a heatsink on it.

Posted

Isn't the RK808 designed to feed the RK3288 - so in this regard it should be able to cope with the load, I guess (as long as you do not overclock) ?

If it does also feed the USB-Hub I can imagine it gets to much without heatsink and you mentioned your heatsink before but without measured degrees - for a human it feels like hot, around 60°C just in average.

  • How hot got your RK808?
  • Is there no thermal sensor in it - does anyone know?

 

Posted
Just now, Tido said:

Isn't the RK808 designed to feed the RK3288 - so in this regard it should be able to cope with the load, I guess (as long as you do not overclock) ?

If it does also feed the USB-Hub I can imagine it gets to much without heatsink and you mentioned your heatsink before but without measured degrees - for a human it feels like hot, around 60°C just in average.

  • How hot got your RK808?
  • Is there no thermal sensor in it - does anyone know?

 

RK808 doesn't have an accessible thermal sensor. It's got two thermal shutdown thresholds and you can set one of 4 high temp thresholds.

You can't get the current temperature, just if it's over the thresholds or not.

Posted (edited)
1 hour ago, chrisf said:

It's got two thermal shutdown thresholds and you can set one of 4 high temp thresholds.

So I read 6 thresholds.

2 x for shutdown, why 2 ?

4 x high temp, of which I can set one. What happens if high temp is reached, throttling of the SoC ?

Edited by Tido
changed clocking with throttling :)
Posted
30 minutes ago, Tido said:

So I read 6 thresholds.

2 x for shutdown, why 2 ?

4 x high temp, of which I can set one. What happens if high temp is reached, down clocking of the SoC ?

It's in the RK808 datasheet

You can set shutdown to 140c or 170C

You can set hot die to 85, 95, 105 or 115C

 

The RK808 driver can then read the shutdown status or the hot die status

http://rockchip.fr/RK808 datasheet V0.8.pdf

Posted

Are kernel is everyone using?

I've been using rockchip-default

I'm having trouble using an SPI device... there is no /dev/spidev* devices, yet I can see there are 3 in the devicetree

-r--r--r-- 1 root root 14 May 26 22:15 /sys/firmware/devicetree/base/aliases/spi0
-r--r--r-- 1 root root 14 May 26 22:15 /sys/firmware/devicetree/base/aliases/spi1
-r--r--r-- 1 root root 14 May 26 22:15 /sys/firmware/devicetree/base/aliases/spi2

From what I can gather, there is no spidev config in the device tree

I see there is a spi2 in the dev and next dts's, are those kernels stable for everyday use or can I apply the patch t the default dts?

Posted

It could be attempted, however I'd guess spidev.c won't take the patch, since those definitions get added to periodically.  (It had to be adjusted from 4.11 to 4.12, for instance).  You can try it, worst case you need to go into spidev.c and manually add the compatibility entry you see in the patch to whatever list of devices is there.

Posted

@chrisf try to build now and let me know.  I'll be out town for a few days for the holiday here in the US, but I'll keep tabs on the forums.

 

Also, forgot to mention, running for several days on GPIO power, and no HDMI dropouts.

Posted

Hello!

First of all, it's amazing to have armbian for the tinkerboard and it already functioning better than the tinkerOS (at least from my point of view), so great job to everyone involved!
I was wondering if the GPIO pins are fully supported yet, or at least the UART pins, on the current version? used legacy kernel from the website -> Armbian 5.27 Ubuntu Xenial Default 4.4.66


(Hopefully I'm posting in the right thread, kinda just jumped into here... please lemme know if I should open a topic for this or if it's ok to post here)

The reason I'm asking is because I've been trying to program an ESP8266 module over the UART pins of the TinkerBoard (using Arduino IDE and the ESP8266 extension) and as of yet haven't gotten it to work, or do anything.
Maybe the mistake lies in me being unable to use the ESP8266 properly yet, or it lies within the fact that Arduino IDE can't send data over UART pins, or the PINs don't work at all yet... 
But as a matter of fact I can select ttyS0, ttyS1, ttyS2 and ttyS3 in the IDE, making me believe that it actually is recognized.
I would really appreciate a little help or push in the right direction since I've kinda hit a dead end at the moment. (currently I've been using 8 and 10 which is UART1 on the pinmap)

For those that know the ESP8266 module, here's what I've connected:

CH_PD and VCC -> 3.3V
GND -> GND
REST -> 3.3V or GND (to reset I switch it to GND if I understood that correctly)
GPIO0 -> 3.3V
TXD -> TinkerBoard GPIO10
RXD -> TinkerBoard GPIO8

3.3V and GND is supplied from the Tinkerboard as well, but I can change that to an external power supply if necessary, but I figured my power supply (official raspberry pi, 5V 2.5A) is sufficient enough, and the ESP8266 lights up as well.

Hopefully someone here can support me a little bit in this :)

Posted

Like many other boards, even if you have many /dev/ttyS*, it doesn't mean the actual UARTs are enabled in the DeviceTree.

You should probably look in the DTS (or decompile DTB into DTS) to figured out.

When a UART is detected at boot time, you will see it in "dmesg" which will show on which /dev/tttyS* it will be attached.

BTW, if not enabled, UARTs can also be enabled using overlays ...

Posted (edited)

That's honestly quite an information load to chew on. So from what I've gathered in my short time investment:
DTS is the Device Tree given by DTB (from the bootloader), which contains all the devices that "should turn on", practically speaking.
How I can enable UART's via overlay I would understand with the raspberry pi, as it holds a well documented config.txt where I simply change something already there... So the twist is that I'm using a tinkerboard and obviously things work a little differently, when not completely. So, not really a genius on this topic yet nor probably will ever be...

Finding out now via dmesg if my UART's are enabled and on which /dev/ttyS is the thing I'm currently wrapping my head around. Espescially since I'm not the best linux guy yet, barely a beginner, getting it to show me what I need to see is gonna take a little bit.
But thanks, at least pushed me into a reasonable direction of where the problem might be.

Edit:
Noticed that there's PL2302 Driver support activated from the 'dmesg' output. I have such a usb to serial cable lying around so I checked if that works and smiled pretty brightly when it suddenly showed up as USB0 in Arduino IDE. Now I've got to figure out another problem, but more of an esp8266 matter... This works temporarily as a quick fix, I'll check back into how I can get the GPIO UART running once I have more time on my hands, since this project got a deadline.
I want the GPIO to work at some point as it would be much nicer for future projects... So yea... Thanks for the nudge :)

Edited by HackXIt
Posted
Quote

DTS is the Device Tree given by DTB (from the bootloader), which contains all the devices that "should turn on", practically speaking.

It could be defined, but not enabled by default ...

Another to verify DT is using "cat status", for example here checking uart1 and  uart2 on some AllWinner boards :

cat /proc/device-tree/soc/serial@01c28000/status 
okay
cat /proc/device-tree/soc/serial@01c28400/status 
disabled

How to enable uart2 uising overlays ? simply edit /boot/armbianEnv.txt and add "overlays=uart2"

 

In the meantime, yes, using USB-TTL Serial is a good workaround ...

 

Posted
8 hours ago, martinayotte said:

How to enable uart2 uising overlays ? simply edit /boot/armbianEnv.txt and add "overlays=uart2"

which is implemented only to Allwinner boards. For Rockchip boards DT should be edited and recompiled manually.

Posted
3 minutes ago, martinayotte said:

Apologize ! I didn't knew that since all my boards are AllWinner.

I mean it shouldn't be too hard to add configfs support patches to these kernels, but you will still need to write overlays for each platform from scratch since base DT configuration will be different.

Posted
12 hours ago, zador.blood.stained said:

I mean it shouldn't be too hard to add configfs support patches to these kernels, but you will still need to write overlays for each platform from scratch since base DT configuration will be different.

How do we going about doing this?

Posted

When I try to start UFW I get an error message.
Do you know what the problem is?
Might be the wrong thread but I'm not sure if the problem is Armbian, Rockchip, UFW or the Linux beginner using the keyboard :D

 

ERROR: problem running ufw-init
modprobe: FATAL: Module nf_conntrack_netbios_ns not found in directory /lib/modules/4.4.66-rockchip
iptables-restore: line 77 failed
iptables-restore: line 30 failed
ip6tables-restore: line 138 failed

Problem running '/etc/ufw/before.rules'
Problem running '/etc/ufw/user.rules'
Problem running '/etc/ufw/before6.rules'

Posted (edited)

There are updated images available

If you don't have the torrent client 'transmission', get it from here https://transmissionbt.com/
Big advantage of torrent, it does automatically check with SHA-key if the file downloaded is okay.


Kernel 4.4.70
no desktop  https://dl.armbian.com/tinkerboard/Ubuntu_xenial_default.7z.torrent
desktop  https://dl.armbian.com/tinkerboard/Ubuntu_xenial_default_desktop.7z.torrent


Edit: reboot works  :thumbup:

/var/log/armhwinfo.log has been uploaded to http://sprunge.us/NVBD

 

MAC-Address still changes:

eth0      Link encap:Ethernet  HWaddr 2c:4d:54:42:c5:6f

eth0      Link encap:Ethernet  HWaddr da:42:ea:69:d7:ca

 

Edited by Tido
Posted

I haven't configured that module in the kernel config, so for this particular issue the newer kernel won't help.  The spidev patch has been committed, has anyone tried using it?

Posted

Hey everyone !

 

Due to some demands, I started to try integrating the Tinkerboard Wifi module, which is nicely implemented in their own kernel. Really, first time I see actual Wifi configuration tools directly integrated into the kernel source tree. Work of art !

 

I don't know if the most important part is the DTS part that seems to hint that the Wireless system is detected through the RFKill subsystem.

Or if that part is kind of a red herring and the most important parts are the ones common to many different RK3288 DTS integrating Wifi, which is a combination of a sdio_pwrseq definition, some pinctrl definitions and an SDIO section definition.

Example on an official RK3288 DTS, rk3288-veyron.dts :

sdio_pwrseq: sdio-pwrseq {
		compatible = "mmc-pwrseq-simple";
		clocks = <&rk808 RK808_CLKOUT1>;
		clock-names = "ext_clock";
		pinctrl-names = "default";
		pinctrl-0 = <&bt_enable_l>, <&wifi_enable_h>;

		/*
		 * On the module itself this is one of these (depending
		 * on the actual card populated):
		 * - SDIO_RESET_L_WL_REG_ON
		 * - PDN (power down when low)
		 */
		reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
	}
&sdio0 {
	status = "okay";

	bus-width = <4>;
	cap-sd-highspeed;
	cap-sdio-irq;
	keep-power-in-suspend;
	mmc-pwrseq = <&sdio_pwrseq>;
	non-removable;
	num-slots = <1>;
	pinctrl-names = "default";
	pinctrl-0 = <&sdio0_clk &sdio0_cmd &sdio0_bus4>;
	sd-uhs-sdr12;
	sd-uhs-sdr25;
	sd-uhs-sdr50;
	sd-uhs-sdr104;
	vmmc-supply = <&vcc33_sys>;
	vqmmc-supply = <&vcc18_wl>;
};

Similar sections can be found in the Tinkerboard's kernel rk3288-miniarm.dts file.

These sections are not present in the official rk3288-tinker.dts, so I created a patch to add it like this :

https://github.com/Miouyouyou/MyyQi/blob/master/patches/kernel/v4.12/0014-Second-tinkerboard-Wifi-driver-addition-tentative.patch

 

However, I don't own the hardware so if anyone can give it a try, while enabling the staging rtl8723bs driver (´・ω・` )

 

 

Also, here's a mainlined Sunxi SoC DTS declaring the driver in a totally different way.

 

Posted

I will take a look, I haven't had much any luck getting it going personally, although I haven't had the time of late (extra work projects/etc)

 

[edit]  oh my, I actually missed the declaration in the Sunxi file entirely... that is different.  x_x

 

[edit 2]  First round no success, compiles but no device, noticed the "wireless-wlan" node was missing, added.  No effect.  :-/

 

Something I saw in the rockchip kernel (common to the Tinkerboard and the MiQi 4.4) was all that intricate management and https://github.com/TinkerBoard/debian_kernel/blob/linux4.4-rk3288/drivers/net/wireless/rockchip_wlan/wifi_sys/rkwifi_sys_iface.c

 

 

Posted

Ah, too bad. Yeah, I've seen that a part of the wireless detection is linked to the RFKill subsystem (Why though...).

 

Is the SDIO part enabled though ?

 

The driver itself seems to rely on SDIO detection ID. I wonder if there's a way to probe any hardware using the SDIO subsystem, a bit like lspci or lsusb , in order to get the hardware ID of hardware available through this protocol.

 

https://github.com/TinkerBoard/debian_kernel/blob/linux4.4-rk3288/drivers/net/wireless/rockchip_wlan/rtl8723bs/os_dep/linux/sdio_intf.c

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/rtl8723bs/os_dep/sdio_intf.c

 

Anyway, I'll try to compile the Tinkerboard version of the driver on the newest kernel, see if it can be done and see if it adds anything.

Posted
config WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP
	bool "Wifi load driver when kernel bootup"
	default y
	---help---
Wifi driver will be load (use late_initcall) when kernel bootup

Is from the kconfig.  I remembered seeing that in the conifgs when I got wifi running on the 4.4 kernel (most of the rockchip stuff is in there, so it was simple)

 

As for what's currently happening:  http://sprunge.us/ZieI

 

That will give you the pertinent bits from my boot in case you're curious, but excerpts:

 

[    1.573208] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    1.573258] mmc1: error -84 whilst initialising SDIO card
[    1.573395] dwmmc_rockchip ff0d0000.dwmmc: card claims to support voltages below defined range
[    1.581858] mmc1: error -110 whilst initialising MMC card

 

[    1.635230] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    1.635285] mmc1: error -110 whilst initialising SDIO card
[    1.635427] dwmmc_rockchip ff0d0000.dwmmc: card claims to support voltages below defined range
[    1.643855] mmc1: error -110 whilst initialising MMC card
[    1.658874] mmc_host mmc1: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
[    1.704513] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    1.704567] mmc1: error -84 whilst initialising SDIO card
[    1.704734] dwmmc_rockchip ff0d0000.dwmmc: card claims to support voltages below defined range
[    1.712853] mmc1: error -110 whilst initialising MMC card

 

Also noticed the io domain entry for the wifi-supply was missing, trying it out.  http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/power/rockchip-io-domain.txt

Posted

Progress!  Meaning the driver module is being loaded but is babbling out errors like crazy!

 

[   59.019326] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin
[   59.019392] rtl8723bs mmc1:0001:1: Direct firmware load for rtlwifi/rtl8723bs_nic.bin failed with error -2
[   59.019403] Request firmware failed with error 0xfffffffe

So, to figure out why the firmware either doesn't exist or isnt being loaded.

 

*update*   I manually dumped the firmware file from https://github.com/hadess/rtl8723bs  into the appropriate directory, disabled/enabled wifi and success!  Now, I don't know what to do about the firmware itself, some how-to would be handy, there is firmware for the BT as well I believe.  I should be able to roll this through both the Next and Dev kernels.

 

In the meantime I'll get the patches out for the device trees and hopefully I can get help with the firmware.

 

Posted
1 hour ago, tkaiser said:

There's https://github.com/armbian/build/tree/master/bin/firmware-overlay/rtlbt (Pine64 and in the meantime also Orange Pi Prime use the same module)

Thanks tkaiser, I obviously didn't look around hard enough.  :-/

 

*update*

 

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

 

4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.

Posted

Following this thread with interest! Has there been any movement on the reboot bug for the latest kernels? Running 4.11 here. 

And thanks for all the hard work! :)

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines