Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Armbian on Tinkerboard
#1
I think I finally got the bug out of the build script, "cat" doesn't like to be silenced, so it throws the baby out with the bath water.   Rolleyes  (the dtb was being tossed out instead of concatenated onto the u-boot image file for burning to the sd image)

The pull request is pending approval, however you should be able to use the Armbian build scripts to produce a working Tinkerboard image once it goes through.  Given the build system tantrums, I haven't been able to look much at hardware support, a caution I can give you is Debian desktop does not give you the option of changing the screen resolution, and my 4k monitor was not happy with whatever it was doing.  Ubuntu Xenial desktop, however, allows you to drop it to 1080p, where it works happily.  I'm assuming it's a refresh rate issue or something similar.


Sound is MIA, I haven't been able to dig into it.

Wifi and BT are no-go at present.

link to basic "how-to" build Armbian.

https://docs.armbian.com/Developer-Guide_Build-Preparation/
Reply
#2
I verified the nightlies work as of today, at least for me. If anyone else is willing to try it out and let me know the outcome:

https://dl.armbian.com/tinkerboard/nightly/Armbian_5.27.170324_Tinkerboard_Ubuntu_xenial_default_4.4.55_desktop.7z

Default boot signin is root, 1234, then you have to immediately change the password and add a user. 4k output behaves badly on my monitor, I had to drop it to 1080p.

The mainline nightly most likely still suffers from not having the device tree for the miniarm in it, I'll look into a patch for that. If you provide the device tree, it boots to desktop as well, only it does not attempt 4k.
Reply
#3
Yes that nightly download works out of the box for me (obviously without wifi/bt)


[Image: nmMtahdm.jpg]
Reply
#4
(03-25-2017, 07:06 PM)Mikerr Wrote: Yes that nightly download works out of the box for me (obviously without wifi/bt)

Thanks to tonymac32 Smile

BT / WiFI ... it's hard to fix those things without actually having the board around. We were promised samples from ASUS by http://tinkerboarding.co.uk/forum/member.php?action=profile&uid=35 but no response so far (one week). Otherwise somebody else would need to take care of those issues. I hate to work on theoretical base. Confused
Reply
#5
Thanks Mikerr,

I had a few days off the radar, there's been a bad flu in this area, was spending some long nights taking care of the kids. From what I understand, a lot of the Tinkerboard support shouldn't be too difficult, I'm just unfortunately learning by doing... ;-)

I'm currently learning more about the device tree and how it works, and comparing 3 different ones I have for the Tinkerboard.
Reply
#6
Hello.

Tested armbian Sad :

- ethernet mac address is radom, please implement right solution from TinkerOS (from eeprom) the device-tree should be updated (eg. i2c2/m24c08@50).

Code:
# read mac-address from eeprom
MAC=`xxd -s 0 -l 6 -g 1 /sys/bus/i2c/devices/2-0050/eeprom | awk '{print $2$3$4$5$6$7 }'`
ifconfig eth0 hw ether $MAC

- video acceleration not installed nor possible (rockchip gits are prepared to build deb packages like "DEB_BUILD_OPTIONS=nocheck debuild -i -us -uc -b -d")
  •   libmali is compilable but fails to start Xorg. (for rk3288 new named packages libmali-rk-midgard-r9p0-r0p0_1.5-4_armhf.deb + libmali-rk-dev_1.5-4_armhf.deb)
Reply
#7
Thanks mcerveny,

As I replied to your post on the Armbian forum, the core devs don't have the board yet, and my knowledge of the Linux kernel is far from complete, I'm a bare-metal embedded software guy, so my progress getting the device tree updated has been slow and not stable enough to commit to the nightly builds as a patch yet.
That said, thank you for the information, I'll look into it and see what I can accomplish in the meantime. I believe someone else on this forum was offering hardware to devs. Also, the Armbian buildsystem is pretty friendly all in all, you could also take a crack at adding some features.
Reply
#8
Hello.

It is terrible situation for all, but some hints - most relevant device-tree is (branch release-20160818-miniarm) https://github.com/rockchip-linux/kernel/blob/release-20160818-miniarm/arch/arm/boot/dts/rk3288.dtsi + https://github.com/rockchip-linux/kernel/blob/release-20160818-miniarm/arch/arm/boot/dts/rk3288-miniarm.dts
At least (compared with armbian generated device-tree) it has vpu-service, hevc-service, wireless-bluetooth, wireless-wlan, ion, vdd_log, sdio-pwrseq ...

But it has not eeprom. The dts/dtsi (and kernel) for TinkerOS sources are not available. I asked ASUS 2x times for disclosure GPL based kernel but no answer (not counting robot saying that ASUS have 48 hours for response.).
Never mind, I used "dtc" to get dts from TinkerOS14, TinkerOS16 and Armbian to get compare (attached) (use some gui (like "meld")). You can search for eeprom registrar under i2c2.
Code:
  i2c@ff660000 {
        ....
        m24c08@50 {
            compatible = "at,24c08";
            reg = <0x50>;
        };
    };

TinkerOS* is funny. It tries to enable more subsystems on multi-purpose pin and generates startup errors.
Code:
kernel: [    0.427872] rockchip-pinctrl pinctrl: pin gpio7-22 already requested by ff680020.pwm; cannot claim for ff690000.serial
kernel: [    0.427936] rockchip-pinctrl pinctrl: pin-238 (ff690000.serial) status -22
kernel: [    0.427979] rockchip-pinctrl pinctrl: could not request pin 238 (gpio7-22) from group uart2-xfer  on device rockchip-pinctrl
kernel: [    2.815969] rockchip-pinctrl pinctrl: pin gpio7-19 already requested by ff980000.hdmi; cannot claim for ff170000.i2c
kernel: [    2.816031] rockchip-pinctrl pinctrl: pin-235 (ff170000.i2c) status -22
kernel: [    2.816073] rockchip-pinctrl pinctrl: could not request pin 235 (gpio7-19) from group i2c5-xfer  on device rockchip-pinctrl

Next funny is new led handling in TinkerOS16 ("cpu0-led" does not exists and "act-led" was "attached" to wrong pin in TinkerOS14):
Code:
    gpio-leds {
        compatible = "gpio-leds";
        pwr-led {
            gpios = <0x45 0x3 0x0>;
            linux,default-trigger = "default-on";
        };
        act-led {
            gpios = <0x8a 0x18 0x1>;
            linux,default-trigger = "mmc0";
        };
        cpu0-led {
            gpios = <0x8a 0x19 0x1>;
            linux,default-trigger = "cpu0";
        };
    };


Happy hacking, Martin


Attached Files
.zip   tinker_decompiled_dts.zip (Size: 26.5 KB / Downloads: 9)
Reply
#9
Yes, I was just about to pull the DTB and decompile from Tinker OS 1.6, I also noticed no E2PROM in the DTS on the miniarm branch. I did it on 1.4 but of course didn't want to hack a bunch of hex into the DTS for Armbian, and my experience with Tinker OS 1.4 told me not to trust it too much... I made note in the Armbian forum that I was able to compile with the miniarm branch DTS (I've had some issues modifying the default one in Armbian, I need to track down the patch that added it to figure out it's origin).

The LED's work on 1.6, they have never worked before with any other distro, so I was surprised by that.

I am really frustrated by the lack of source availability for Tinker OS. I was poking around the Linaro Git and found nothing of value.

Of course the DTS submitted to kernel.org is... well... : https://patchwork.kernel.org/patch/9571625/

Thank you Martin,
-Tony
Reply
#10
Device tree for Armbian updated, pull request merged this morning, should be in tomorrow's nightly build. No kernel driver patches yet, but the LED's actually work, and the vopl/vopb bug is fixed. A lot of other changes, but like I said only things with built-in kernel support will show up.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)