TonyMac32

So, with the now-working U-Boot setup, the only thing to get the Dev image with Kernel 4.11 working is a device tree for the miniarm. Trouble is, I don't know how to go about patching that.

Just a thought. the boot loader offset locations *should* be hardware bound by the SoC, there shouldn't be any difference between MiQi and Tinker Board unless the MiQi is using an SPI device to load a bootloader, but that does not sound like the case. With the cat command throwing it's data away instead of adding it to the output binary, the Tinker Board did exactly as you describe here, only showed the U-Boot SPL message.

I downloaded and tested the kernel 4.4 nightly, it works as hoped.

Forgot to mention: It works for me with that single adjustment. I was trying to see if there were errors and it suddenly worked, so I turned the problem back on and back off again to verify. _____ _ _ _ _ |_ _(_)_ __ | | _____ _ __| |__ ___ __ _ _ __ __| | | | | | '_ \| |/ / _ \ '__| '_ \ / _ \ / _` | '__/ _` | | | | | | | | < __/ | | |_) | (_) | (_| | | | (_| | |_| |_|_| |_|_|\_\___|_| |_.__/ \___/ \__,_|_| \__,_| Welcome to ARMBIAN 5.27 stable Ubuntu 16.04.2 LTS 4.4.55-rockchip System load: 0.00 Up time: 1 hour Local users: 2 Memory usage: 10 % of 2011Mb IP: 10.0.0.35 CPU temp: 45°C Usage of /: 15% of 15G storage/: 97% of 30G tony@tinkerboard:~$ I also played with the dev release just for kicks, there is no "miniarm" or tinkerboard dtb in there, so I copied one over from my other drive and it fired right up to desktop. |_ _(_)_ __ | | _____ _ __| |__ ___ __ _ _ __ __| | | | | | '_ \| |/ / _ \ '__| '_ \ / _ \ / _` | '__/ _` | | | | | | | | < __/ | | |_) | (_) | (_| | | | (_| | |_| |_|_| |_|_|\_\___|_| |_.__/ \___/ \__,_|_| \__,_| Welcome to ARMBIAN 5.27.170322 nightly Ubuntu 16.04.2 LTS 4.11.0-rockchip System load: 1.21 Up time: 33 sec Memory usage: 7 % of 2007Mb IP: 10.0.0.37 CPU temp: 44°C Usage of /: 15% of 15G [ 7 updates to install: apt upgrade ] To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. tony@tinkerboard:~$

I tried a few odds and ends last night, I'm going to have to break out the hex editor and compare the initial image to what results when I use the commands on the SD directly. [edit] Somehow the u-boot-dtb.bin is still not getting into the image. It should be living at sector 132 according to the drive I have that boots, but was nowhere to be found in the image file. ... So, are you ready for this? the "> /dev/null 2<&1" to snuff out the output was making it throw the entire command into the bitbucket. Pull request submitted for the change.

I'll play with the build later today and test, there was the question I struck out about whether or not the write_uboot_platform() function is overriding the other when the if [[$board == tinkerboard]] condition is true. I abandoned it upon finding the image/binary difference. [edit] Pull request in to make the write_uboot_platform in the tinkerboard if block use the .bin That did not solve it by itself, I just noticed it when I took a quick look.

@Igor, I'll check it out once I get home from work. I only noticed because I typed the commands looking at my forum post, not at the script. It yelled at me so I was forced to look at the filenames... @Myy, yes, I saw that was one of the operating modes when the device saw no bootable media. Is there any utility for that mode without NAND media?

:-/ it won't boot again. if I run the commands manually with the resulting SD it works perfectly (including the fix for the dtb), but it's somehow not writing to the image correctly. Perhaps the original definition for the MiQi isn't being overridden by the one in the if block? I manually followed the script and noticed "u-boot-dtb.img" was in the package, not "u-boot-dtb.bin". Manually performing the flash using the package contents failed boot, while using the U-Boot folder directly worked. The bin is 64 bytes smaller than the img. I repeated the failed process and used the *.bin instead and the board booted. [last edit] I am testing using dd if=$1/u-boot-dtb.img bs=64 skip=1 >> out To skip that header.

Hello from Armbian! 4K output is configured by default, however my monitor was not behaving properly. Otherwise USB, ethernet, etc are working, And it is smoother than the ASUS tinkerOS 1.4 It could be that the MiQi is more robust bootloader wise, it might be able to overlook some formatting differences on the SD card where the Tinker Board cannot, my net crawling did uncover some comments to that effect concerning the Tinker Board being "inflexible".

Thanks Igor, I was getting exactly 1 line from the serial console: U-Boot SPL 2017.03-rc3-armbian (Mar 19 2017 - 14:17:16) A question was raised about using Armbian on the tinkerboarding forum tkaiser mentioned in another thread, I put a comment as to my progress, got a reply from another user on the forum thread with a different U-boot burning procedure than is in the build script: tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out cat u-boot-dtb.bin >> out sudo dd if=out of=/dev/sdb seek=64 conv=notrunc (obviously /dev/sdb would be the image file in the case of the build script, I executed this directly onto the SD I had already flashed with the complete image) This was a success, at least as far as the U-Boot issue is concerned: U-Boot SPL 2017.03-rc3-armbian (Mar 19 2017 - 14:17:16) U-Boot 2017.03-rc3-armbian (Mar 19 2017 - 14:17:16 -0400) Model: Tinker-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c0000: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: Error: ethernet@ff290000 address not set. No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 1446 bytes read in 20 ms (70.3 KiB/s) ## Executing script at 00000000 U-boot loaded from eMMC 102 bytes read in 17 ms (5.9 KiB/s) ** File not found /boot/dtb/rk3288-miniarm ** ** Unrecognized filesystem type ** ** File not found dtb/rk3288-miniarm ** 4668288 bytes read in 362 ms (12.3 MiB/s) 7418384 bytes read in 560 ms (12.6 MiB/s) ## Loading init Ramdisk from Legacy Image at 21000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4668224 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree SCRIPT FAILED: continuing... => So, to track down the device tree issue... [EDIT] I simply knocked the ".dtb" extension off of the device tree in /boot/dtb/ and I'm at the linux command line on the HDMI output.

OK, so the U-Boot SPL is loading, but I believe it is dying when it returns to BROM, the RK3288 is not finding the actual U-boot image for some reason. Would it be possible to post the console output from booting the MiQi?

I built the rockchip linux just to make 110% sure it worked, I'm posting from it now. Can barely read what I'm typing, 4K output on the gui without scaling the text... @tkaiser: I assumed nothing actually shocked you, it was just a bit of fun is all.

Well, I'm throwing in the towel for a little bit, trying to go over the build scripts for the rockchip linux and Armbian has my head fuzzy, especially since I'm not familiar with them. the U-Boot mainline gives no output on either UART, so for anyone wishing to experiment: go to (build folder)/lib/config/sources/rockchip.conf replace the original: if [[ $BOARD == "tinkerboard" ]]; then BOOTSOURCE=$MAINLINE_UBOOT_SOURCE BOOTDIR=$MAINLINE_UBOOT_DIR BOOTBRANCH="branch:master" fi with if [[ $BOARD == "tinkerboard" ]]; then BOOTSOURCE='https://github.com/rockchip-linux/u-boot.git' BOOTDIR='u-boot-rk-linux' BOOTBRANCH="branch:release" fi Like I said before, this will at least get you the "Hello, I'm U-Boot" message on UART2. Why it won't go past there I'm not completely sure yet, honestly with the number of config files all over I'm not certain of what I should be looking at.

...Literally? Oh dear... :-D

Pulled out the hex editor to get a closer look at the bootloader to see if it was putting everything where it belongs, and I figured out why I can't see serial terminal, it's on UART2 in this build instead of UART1 like on the ASUS build. So that explains that mystery. I'm sure the sources could have told me that, but somehow the hex editor was easier to follow... I also see references to the now-gone eMMC, so it's probably trying to boot that and hanging. Can't get the build script to give me serial 1 instead of serial 2, but I did change the U-Boot source to the Rockchip Linux one, and I made an even more interesting adapter to ttyS2 and got this: U-Boot SPL 2017.03-rc3-armbian (Mar 14 2017 - 23:21:19) It hung right away just like the mainline, I'm learning my way around to see if it's a device number issue, I'm still seeing the dwmmc@ff0f0000 (that's the eMMC address) popping up in the binary (less than with mainline), I haven't figured out where to turn that off if it's being passed as a parameter somewhere.

Board revision 1.2. Tinker OS 1.3 and 1.4 both worked. Given the dubious nature of the release, I'm not going to assume all the boards are the same hardware rev level.

Yes, mine is Rev. 1.2 if that helps.

Looking through the source, the tinker_rk3288.h in the build directory of what I built vs the one at Rockchip linux has a correction on the boot target device number from func(MMC, mmc, 0) to func(MMC, mmc, 1) I could see it stalling the boot, but no serial out? Apparently these were originally configured with an eMMC... https://github.com/rockchip-linux/u-boot/commit/d57b7e1f6707ee5e834e0b2c9ceeaf558455ff4b If I change this in my source files and rebuild, will it be preserved or will the build replace it with the original? (noob question, sorry) [EDIT] Found the script option to turn off checkout. Trying it. [EDIT 2] I'm afraid that single adjustment didn't fix it. It's time to sleep for me, I'll be back later. ;-)

I hacked an adapter for my FTDI Friend together, I tried the default MiQi image, there is nothing on the serial port. I assumed 115200 8N1, is that correct? The output from the ASUSimage looks like this: cap 2048 chipsize_mb=1024 chipsize_mb=1024 size_mb = 2048 U-Boot 2016.09-rc1 (Feb 23 2017 - 17:59:51 +0800) Model: Miniarm-RK3288 DRAM: chipsize_mb=1024 chipsize_mb=1024 size_mb = 2048 2 GiB MMC: dwmmc@ff0c0000: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf reading /extlinux/extlinux.conf 140 bytes read in 6 ms (22.5 KiB/s) Retrieving file: /hw_intf.conf reading /hw_intf.conf 109 bytes read in 4 ms (26.4 KiB/s) hw_conf.valid = 1 hw_conf.i2c1 = 1 hw_conf.i2c4 = 1 hw_conf.spi2 = 1 hw_conf.pwm2 = 1 hw_conf.pwm3 = 1 hw_conf.uart1 = 1 1: kernel-4.4 Retrieving file: /zImage reading /zImage 6731160 bytes read in 497 ms (12.9 MiB/s) append: earlyprintk console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init uboot_version=2016.09-rc1 Retrieving file: /rk3288-miniarm.dtb reading /rk3288-miniarm.dtb 45592 bytes read in 8 ms (5.4 MiB/s) ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Device Tree to 1fff1000, end 1ffff617 ... OK Starting kernel ...

I'll set up a VM and try to build it. Be patient, my software experience is with *much* lower level things (assembly language and firmware) Igor, thanks for all the hard work!

I'll take a look at that parameter. Out of the box I get a power light and absolutely nothing else using the MiQi image.

@tkaiser I wouldn't bet on anyone in that forum being an ASUS rep. [EDIT] @Mikerr is the forum owner, he's posted in here asking about progress on the Tinker Board. [/EDIT]That said, Asus hasn't demonstrated a lot of interest in their own product, at least not publicly... I tried the MiQi image on my tinkerboard, no HDMI output and no power to any peripherals. I'm guessing it's the Rockchip power management IC (RK808), since everything else is directly tied to the SoC. I don't have a 64-bit machine to dedicate to Ubuntu for building Armbian, but I'll see what I can scratch up. First things first is to tap into tty0

Apologize for back-to-back posts, but Asus just released an updated image for the Tinker Board, available on their uk site: https://www.asus.com/uk/Single-board-Computer/TINKER-BOARD/ I'm getting ready to test it, thought I'd post in case anyone else was interested.

I can confirm this, thank you for the info, on the NanoPi NEO Air I'm getting similar results testing my heat sink solution: Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 01:47:08: 912MHz 0.53 0% 0% 0% 0% 0% 0% 33°C 01:47:13: 240MHz 0.49 0% 0% 0% 0% 0% 0% 33°C 01:47:18: 240MHz 0.49 0% 0% 0% 0% 0% 0% 33°C 01:47:24: 240MHz 0.45 0% 0% 0% 0% 0% 0% 33°C <snip> 01:51:12: 912MHz 3.87 0% 0% 0% 0% 0% 0% 45°C 01:51:17: 912MHz 3.88 0% 0% 0% 0% 0% 0% 46°C 01:51:22: 912MHz 3.89 0% 0% 0% 0% 0% 0% 46°C 01:51:28: 912MHz 3.90 0% 0% 0% 0% 0% 0% 46°C 01:51:33: 912MHz 3.91 0% 0% 0% 0% 0% 0% 46°C 01:51:38: 912MHz 3.92 0% 0% 0% 0% 0% 0% 46°C 01:51:43: 912MHz 3.92 0% 0% 0% 0% 0% 0% 46°C 01:51:48: 912MHz 3.93 0% 0% 0% 0% 0% 0% 46°C 01:51:54: 912MHz 3.94 0% 0% 0% 0% 0% 0% 46°C 01:51:59: 912MHz 3.94 0% 0% 0% 0% 0% 0% 46°C <snip> 01:54:39: 912MHz 4.08 0% 0% 0% 0% 0% 0% 49°C At least the heatsink works, I used thermally conductive epoxy to attach a fair-sized heatsink to the CPU, that thermal pad they give is not very good. It appeared to level off at around 52 C 15 minutes in.

That's interesting. I wasn't sure what to make of the inconsistent "upscaled from 1080" notes I've found here and there, and got more confused with the entire mouse thing. There's very little in the way of strange hardware physically on the board, although there is an 8k EEPROM on the bottom side next to the SD card that I can't really account for. Power wise it's using a Rockchip RK808-B, which should mean the SoC has access to battery management and a real time clock, if everything is broken out. To that end there are 2 connections available between the HDMI and Micro-USB, I haven't been brave enough to probe them fully, I'd assume one is purely a 5V in, the other may be for a battery or a hardware reset switch. I'm looking over the datasheets and the (far from complete) schematic. [edit] There is a USB charge monitor onboard: http://www.ti.com/lit/ds/symlink/bq24392.pdf