Jump to content

RK3328 Kernel

Peba

By Peba
in Tinkerboard

 Share

Recommended Posts

TonyMac32

TonyMac32

Posted
Posted

Built, no longer getting the "error, address not set" on the ethernet at boot.  Getting late, can't dig in much further but I'd guess it's a success.

1
gkkpch

gkkpch

Posted
Posted

Something else, I can't get reboot to work, does anyone have an idea where to start looking?

Any hint would be appreciated.

TonyMac32

TonyMac32

Posted
Posted

I'm afraid not, I played with it briefly but couldn't get any meaningful information on where it was getting hung up from logs.  It looks like it makes it to shutdown just fine, but hangs on the actual restart as if it's not pointing at the right location on soft reset.

 

[Edit] With some research into the ASUS kernel, determined cause to be power being disabled to the SD card, a somewhat hack-ish workaround is in place, patch merged.

Tido

Tido

Posted
Posted

Yeah, a working reboot while testing would be really useful.

When I google'd it I saw that it takes some know-how about working with kernel and or SDK (which I don't have). I would be more than happy to give someone access to my Board via AnyDesk or such.

 

By the way, for Desktop users of Tinker Board, read this: ASUS Tinker Boards Get Linux 4.11 with 3D Graphics Acceleration

Igor

Igor

Posted
Posted

I changed DEV branch to NEXT today ... so you need to switch branches or start with new image. Tomorrow nightly builds will also be branch NEXT.

 

BTW. MiQi with 4.11 and mainline u-boot reboots fine.

gkkpch

gkkpch

Posted
Posted

FYI: I compiled two Tinkerboard 4.4 kernels today, one from kwiboo's repo, branch "tinkerboard-4.4" and the one I got from Asus directly, they now published it as the TinkerBoard repo

Kwiboo's boots and reboots, but so does the one from the Asus TinkerBoard repo. Actually including onboard WLAN and also working as a hotspot.

Don't use GCC6 on Kwiboo's, unless you want to spend your time bug fixing (e.g. misleading indentation etc. ), in the end I just disabled the restrictive checking in the Makefile. 

TonyMac32

TonyMac32

Posted
Posted

Uploading patch to fix reboot on Tinker board 4.4 kernel.  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)

1
lucifercipher

lucifercipher

Posted
Posted

Got the tinkers today and fired it up with 4.4.66-rockchip default (no desktop) .I see its a 32bit so far. Noticed the SoC is clocked at 1608 Mhz. Did some quick benchmarks for 20k primes and uploaded here:

 

http://orangepi.cryptoedge.net/SoC Benchmarks.txt

http://orangepi.cryptoedge.net/SoC Bemchmarks Multi Threaded.txt

 

Log uploaded: http://sprunge.us/dWic

 

Every 2.0s: cat /proc/sys/kernel/random/entropy_avail                                                 Fri May  5 09:51:54 2017

 

1995 (almost half compared to H5 SoC) :/
 

 

First impression. The heat sink should be having more mass than this tiny one.  Testing starts now...

tkaiser

tkaiser

Posted
Posted
14 minutes ago, lucifercipher said:

Did some quick benchmarks for 20k primes

 

No, not that again! ;)

 

Sysbench's cpu 'benchmark' is NOT a hardware test.

 

By looking at your numbers Orange Pi PC 2 is 9.5 times faster than Tinkerboard. Who should believe this? :)

 

TL;DR: Sysbench doesn't test hardware.

1
lucifercipher

lucifercipher

Posted
Posted

Yeah its not a hardware test but just a comparison with other three SoCs. Is there a nightly 64bit available right now? The idle temps also seem higher compared to Pi3,2 , AWH3 and AWH5. 

lucifercipher

lucifercipher

Posted
Posted
5 minutes ago, tkaiser said:

 

By looking at your numbers Orange Pi PC 2 is 9.5 times faster than Tinkerboard. Who should believe this? :)

 

Hmm well what i can do is upload screenshots instead of text outputs . Would be something better?

 

tkaiser

tkaiser

Posted
Posted
1 minute ago, lucifercipher said:

Yeah its not a hardware test but just a comparison with other three SoCs.

 

No, it's a comparison with other sysbench binaries running here and there with different compiler settings. Numbers without meaning in this mode unfortunately. And no, Cortex-A17 is 32-bit so not 64-bit capable. But since all affordable 64-bit platforms currently are based on dog-slow Cortex-A53 that doesn't matter at all :) 

tkaiser

tkaiser

Posted
Posted
10 minutes ago, constantius said:

Armbain for Tinkerboard is not stable - system hang on very often

 

Great report! Has anyone in the meantime figured out how to power this board avoiding Micro USB? To prevent 'Armbian is not stable' findings in the future?

tkaiser

tkaiser

Posted
Posted
17 minutes ago, richardk said:

Didn't you see? http://www.96boards.org/product/hikey960/

 

I've seen this but I won't call this thing affordable and I'm not that crazy (I won't buy overpriced Android phones without enclosures especially not when questionable agencies are responsible for f*cking up product documentation. My opinions on HiKey boards here or there)

 

Back on topic: some homework for you Tinkerboard owners: https://forum.armbian.com/index.php?/topic/4200-pi-fan-control-work-on-tinker-board/&do=findComment&comment=31128  :) 

 

TonyMac32

TonyMac32

Posted
Posted

I have seen a lot of temperature variation from image to image (not Armbian, I'm talking from ASUS's images, Rockchip-linux build, etc).  CPU op points and temperature trip points are moving around a lot, I haven't been taxing mine all that hard, mostly doing quick "did my patch work" checks.

 

I checked my router, the last 3 bytes of my MAC address are still seemingly random, it should be stable between builds/images, correct?

 

As far as powering the tinker board goes, I see no way to bypass the microUSB yet, I need to try to probe "USBIN_VBUS_80" on the board itself, otherwise any solution will be extremely hack.  If lucky there is a tespoint somewhere that can be used.

lucifercipher

lucifercipher

Posted
Posted

@TonyMac32I didn't want to be bothered by the power issue so i used a Samsung S7 Edge USB cable with the Aukey certified power brick .  I see that the CPU starts to throttle around 71C .  In any case, the USB power input seems like a big joke .

TonyMac32

TonyMac32

Posted
Posted

I'm using some cables I spec'd online, I can' tremember the exact source, however their voltage drop is minimal and so far they've worked well.  That said I'd prefer a better solution, if someone were to take care to use adequate protection, it looks like putting 5V on the GPIO (pins 2-3) will supply VCC_SYS, which is what the RK808 uses to get all the system voltages.  You'd only be missing the surge suppressor, current limiter, and usb charge detector. (that one might be a sticking point, I think it might signal power OK)

1
tkaiser

tkaiser

Posted
Posted
7 minutes ago, TonyMac32 said:

it looks like putting 5V on the GPIO (pins 2-3) will supply VCC_SYS, which is what the RK808 uses to get all the system voltages.  You'd only be missing the surge suppressor, current limiter, and usb charge detector.

 

Would be great if you can further investigate here since due to RK3288 being quite powerful and powering through Micro USB being such a sh*t show a warning like this might be necessary (but on Pine64 there's no difference between GPIO pins on Euler connector or Micro USB unlike Raspberries or the Tinkerboard now)

Tido

Tido

Posted
Posted

Please take all of this with a grain of salt - I was just collecting information for RPi-Monitor and came across this.

 

@TonyMac32 I tried to read out: cat /sys/class/regulator/regulator.13/microvolts

It stays in idle and benchmark at 1000000 (I suppose 1Volt).  So I suppose this is hardcoded in DTS ?

Because in this thread I read : 

> +		regulator-min-microvolt = <850000>;
> +		regulator-max-microvolt = <1350000>;

 

Normally the max voltage is 1.4v  says this overclocker Overclocking RK3288

 

Edit, found one more interesting: altghough I still do not support 1,8GHz 

+&cpu0 {
+	cpu0-supply = <&vdd_cpu>;
+	operating-points = <
+		/* KHz    uV */
+		1800000	1400000
+		1608000	1350000
+		1512000 1300000
+		1416000 1200000
+		1200000 1100000
+		1008000 1050000
+		 816000 1000000
+		 696000  950000
+		 600000  900000
+		 408000  900000
+		 312000  900000
+		 216000  900000
+		 126000  900000
+	>;

 

TonyMac32

TonyMac32

Posted
Posted
6 hours ago, Tido said:

Please take all of this with a grain of salt - I was just collecting information for RPi-Monitor and came across this.

 

@TonyMac32 I tried to read out: cat /sys/class/regulator/regulator.13/microvolts

It stays in idle and benchmark at 1000000 (I suppose 1Volt).  So I suppose this is hardcoded in DTS ?

Because in this thread I read : 


> +		regulator-min-microvolt = <850000>;
> +		regulator-max-microvolt = <1350000>;

 

Normally the max voltage is 1.4v  says this overclocker Overclocking RK3288

 

Edit, found one more interesting: altghough I still do not support 1,8GHz

 

 

 

regulator.13 is vdd10_lcd, you want regulator.4, vdd_arm

 

 

1
TonyMac32

TonyMac32

Posted
Posted

I am going to attempt to put the reboot patch in there tonight and get some more dts work done, I'm afraid none of the rockchip wifi system interface is built into the 4.11 kernel.  I'll take a look at 4.12 to see how much work I want to put into it, and of course look at some other rockchip-oriented kernels to see if they have it implemented or not.  Remember we don't have working BT in the 4.4 either.  And then there's the sound issue, which should just be an ALSA configuration and maybe a PA fix, if someone else wanted to start looking into that.  ;-)

1
lucifercipher

lucifercipher

Posted
Posted
12 hours ago, TonyMac32 said:

I am going to attempt to put the reboot patch in there tonight and get some more dts work done, I'm afraid none of the rockchip wifi system interface is built into the 4.11 kernel.  I'll take a look at 4.12 to see how much work I want to put into it, and of course look at some other rockchip-oriented kernels to see if they have it implemented or not.  Remember we don't have working BT in the 4.4 either.  And then there's the sound issue, which should just be an ALSA configuration and maybe a PA fix, if someone else wanted to start looking into that.  ;-)

 

I understand where you are coming from. If it helps, the TinkerOS beta 1.8 release has addressed those problems.  Could be a reference perhaps? I did not find the source code for it. 

1
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept