• Before reporting problems with your board running Armbian, check the following:

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  

    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

preview Asus Tinkerboard
29 29

434 posts in this topic

Hmmm, no idea, that doesn't actually look like a bluetooth keyboard, to be honest, it's just popping up as a standard generic HID device.

 

[    1.996363] usb 1-1.3: new low-speed USB device number 3 using dwc2
[    2.079542] usb 1-1.3: New USB device found, idVendor=046e, idProduct=5577
[    2.079556] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.079566] usb 1-1.3: Product: USB Multimedia Cordless Keyboard
[    2.079574] usb 1-1.3: Manufacturer: BTC
[    2.083962] input: BTC USB Multimedia Cordless Keyboard as /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046E:5577.0001/input/input0
[    2.135850] hid-generic 0003:046E:5577.0001: input,hidraw0: USB HID v1.11 Keyboard [BTC USB Multimedia Cordless Keyboard] on usb-ff540000.usb-1.3/input0
[    2.143143] input: BTC USB Multimedia Cordless Keyboard as /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:046E:5577.0002/input/input1
[    2.195087] hid-generic 0003:046E:5577.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [BTC USB Multimedia Cordless Keyboard] on usb-ff540000.usb-1.3/input1

perhaps if you could boot the other images that don't recognize it, with it plugged in, and do the same thing?  I'm kind of curious now...

Share this post


Link to post
Share on other sites

I would if I could, but I've no way to log into the device on the standard images as this is my only keyboard! Maybe they'd let me borrow one from work.

 

I have to say thanks thanks for all your work and input in this thread. When I got this device I was unaware of armbian, and happened to discover it because you posted a link in the asus forum: https://tinkerboarding.co.uk/forum/thread-330.html

 

I found armbian and its users so interesting I must have read this entire thread two or three times! If you follow the link above you can see how I followed your example with GPIO power and an uprated heatsink and was able to hacksaw a hole into my case and attach a little fan! You can even see my dongle :o

Igor and TonyMac32 like this

Share this post


Link to post
Share on other sites
On 7/25/2017 at 5:43 AM, RickyTerzis said:

external HDD's assuming they won't spin up on the USB alone.

I haven't had a problem powering a 2.5" hard drive from the USB port

 

It's much better than my Pine64 boards. They reboot when plugged in and the hard drive refuses to spin up.

Share this post


Link to post
Share on other sites

Try to execute lsmod on the working kernel. Since most drivers are compiled modules, that should tell you what is the driver, I think. Then, from the module name, you can retrace the config option required and its dependencies.

 

It might also be possible to determine the driver used using /sys nodes. But I don't know how exactly. udevadm can also help you.

 

But yeah, try lsmod first.

bedalus likes this

Share this post


Link to post
Share on other sites

We could just be overthinking it, the Next download jumped from 4.11 to 4.12.3, could just be an updated module, rather than a new one.  

Share this post


Link to post
Share on other sites

But wait... you got Bluetooth working on 4.12 kernels ? Are you using an external Bluetooth dongle or did you just start your Bluetooth keyboard and it worked out the box ?

 

Edit : Ah, didn't read correctly, you're using an external dongle. Well given the bad feedback I got from the tinkering forum on the internal Bluetooth, I guess it's the best choice.

lafalken likes this

Share this post


Link to post
Share on other sites

The BTCOEX and such used by ASUS is several revisions back and, if the Mainline work on the wifi driver any indication, probably buggy.

Share this post


Link to post
Share on other sites
root@tinkerboard:/home/bedalus# lsmod
Module                  Size  Used by
snd_soc_hdmi_codec     16384  0
r8723bs               552960  0
dw_hdmi_i2s_audio      16384  0
mali_kbase            319488  0

Nothing to see with lsmod. However, udevadm gives me:

root@tinkerboard:/home/bedalus# udevadm info --query=all /dev/input/by-id/usb-BTC_USB_Multimedia_Cordless_Keyboard-event-kbd 
P: /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046E:5577.0001/input/input0/event0
N: input/event0
S: input/by-id/usb-BTC_USB_Multimedia_Cordless_Keyboard-event-kbd
S: input/by-path/platform-ff540000.usb-usb-0:1.3:1.0-event-kbd
E: BACKSPACE=guess
E: DEVLINKS=/dev/input/by-path/platform-ff540000.usb-usb-0:1.3:1.0-event-kbd /dev/input/by-id/usb-BTC_USB_Multimedia_Cordless_Keyboard-event-kbd
E: DEVNAME=/dev/input/event0
E: DEVPATH=/devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046E:5577.0001/input/input0/event0
E: ID_BUS=usb
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_MODEL=USB_Multimedia_Cordless_Keyboard
E: ID_MODEL_ENC=USB\x20Multimedia\x20Cordless\x20Keyboard
E: ID_MODEL_ID=5577
E: ID_PATH=platform-ff540000.usb-usb-0:1.3:1.0
E: ID_PATH_TAG=platform-ff540000_usb-usb-0_1_3_1_0
E: ID_REVISION=0310
E: ID_SERIAL=BTC_USB_Multimedia_Cordless_Keyboard
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:030101:030102:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=BTC
E: ID_VENDOR_ENC=BTC
E: ID_VENDOR_ID=046e
E: MAJOR=13
E: MINOR=64
E: SUBSYSTEM=input
E: USEC_INITIALIZED=4130433
E: XKBLAYOUT=us
E: XKBMODEL=pc105

So usbhid. I think I'll borrow a keyboard from work then we can find out for sure. IKONFIG is set, so if I'm able to use a different keyboard and log in, I can diff the exact config used against the nightly.

Share this post


Link to post
Share on other sites

My tinker board appears to have crashed again after 1.8 weeks of uptime.
Power supply is the micro-USB "official" RPi one, and it's rated at 2.5A , the SD card appears to be fine.

Symptoms:

  1. Only the red led was powered on, I had no green (I/O) or yellow led (heartbeat) activity.
  2. When removing the power cord and reinserting it, it would power-on for a couple of seconds and then it would power-off by itself.
  3. I left it powered-off for around 2 minutes and then powered it on and it's working ok so far.
  4. I checked my graphs and I see that over the course of the last 2 weeks, the CPU was sustaining temps between 61-65.5 °C.
  5. Right now I'm noticing a 74°C temperature spike, which is slowly coming down to the previously observed temperatures. (This graph displays the last 24h)
    Temps2.png.595a85548a1499807bfe50c8bbdf23c4.png

I'm not sure why the CPU raises it's temperature if the system has crashed. I've also reviewed the syslog and kernel logs, but I cannot find anything that would point me to the cause of the crash.

It also must've refused to start because it was overheated, but why does it always work fine for almost two weeks and then suddenly decides to die? I would appreciate any pointers to help me investigate.

Using mainline kernel.

root@Tuxbox:~# lsb_release -a && uname -r
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial
4.11.6-rockchip

 

Share this post


Link to post
Share on other sites

IIRC, because of Log2Ram it will not write to SDcard when it crashes. You would have to write the data/logs to another storage device USB-Stick or something externally.

Beside with RPi-Monitor you might also be able to collect some data - is WIP.

Frostbyte likes this

Share this post


Link to post
Share on other sites
17 minutes ago, Igor said:

Power via GPIO.


Are there any instructions available? Any precautions, etc? Thanks.
PS: In the meantime, can I somehow downclock the SoC a little bit? Would that help any?

Share this post


Link to post
Share on other sites
On 2017-7-26 at 5:53 AM, TonyMac32 said:

Hmmm, no idea, that doesn't actually look like a bluetooth keyboard, to be honest, it's just popping up as a standard generic HID device.

 


[    1.996363] usb 1-1.3: new low-speed USB device number 3 using dwc2
[    2.079542] usb 1-1.3: New USB device found, idVendor=046e, idProduct=5577
[    2.079556] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.079566] usb 1-1.3: Product: USB Multimedia Cordless Keyboard
[    2.079574] usb 1-1.3: Manufacturer: BTC
[    2.083962] input: BTC USB Multimedia Cordless Keyboard as /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046E:5577.0001/input/input0
[    2.135850] hid-generic 0003:046E:5577.0001: input,hidraw0: USB HID v1.11 Keyboard [BTC USB Multimedia Cordless Keyboard] on usb-ff540000.usb-1.3/input0
[    2.143143] input: BTC USB Multimedia Cordless Keyboard as /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:046E:5577.0002/input/input1
[    2.195087] hid-generic 0003:046E:5577.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [BTC USB Multimedia Cordless Keyboard] on usb-ff540000.usb-1.3/input1

perhaps if you could boot the other images that don't recognize it, with it plugged in, and do the same thing?  I'm kind of curious now...

 

Well, I was allowed to borrow a USB keyboard from work, and I flashed the standard version with the mainline kernel, and...

[    2.033927] usb 1-1.3: new low-speed USB device number 3 using dwc2
[    2.116818] usb 1-1.3: New USB device found, idVendor=046e, idProduct=5577
[    2.116831] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.116841] usb 1-1.3: Product: USB Multimedia Cordless Keyboard
[    2.116850] usb 1-1.3: Manufacturer: BTC
[    2.212636] usb 3-1: config 1 has an invalid interface number: 255 but max is 6
[    2.212648] usb 3-1: config 1 has no interface number 6
[    2.214117] usb 3-1: New USB device found, idVendor=0bda, idProduct=481a
[    2.214130] usb 3-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[    2.214139] usb 3-1: Product: USB Audio
[    2.214148] usb 3-1: Manufacturer: Generic
[    2.214156] usb 3-1: SerialNumber: 201405280001

...

[    4.333263] input: Generic USB Audio as /devices/platform/ff500000.usb/usb3/3-1/3-1:1.255/0003:0BDA:481A.0003/input/input1
[    4.385590] hid-generic 0003:0BDA:481A.0003: input,hiddev0,hidraw0: USB HID v1.11 Device [Generic USB Audio] on usb-ff500000.usb-1/input255

 

USB 1-1.3 never gets allocated as an input device, even though it's detected (USB 3-1 later gets a device, which are the bottom two lines after I cut an irrelevant section). So perhaps something to do with some hid options? I took the diff between the configs:

 

> CONFIG_HID_ACCUTOUCH=m
...
> CONFIG_HID_CP2112=m
...
> CONFIG_HID_NTI=m

Not sure if these are relevant, it's difficult for me to guess whether it was a config option that helped, maybe it was just some mainline commit that fixed something between 4.11 and 4.12. 

 

Anyway, if you want to pursue the reason, I've attached the output of armbianmonitor -u and the diff between the two kernel configs. I'm out of ideas, but happy and lucky to have a working cordless keyboard!

armhwinfo.log

config.diff

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
29 29

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.