Rfreire

@chwe @TonyMac32
 
Well, in the end I have bought the 1054Z. And it made its debut sniffing the phone line voltages in order to ensure if is my carrier providing "voltage reversal" upon disconnect. It was not :-P
 
Tony, you might love the discussion (bottom) at https://hackaday.com/2016/10/05/choosing-a-scope-examining-bandwidth/
 
 
 
 

Is it possible to patch the device tree someway to enable HDMI output and having the console on the framebuffer for debugging in current non-development armbian version?
 
Thanks

THE MEDIA SCRIPT IS DEPRECATED, IN FAVOR OF THE OFFICIAL LEGACY MULTIMEDIA FRAMEWORK. PLEASE REFER TO THIS TOPIC:
 
 
 
The UN-official, UN-supported, UN-necessary, UN-popular, UN-precedented...
RK3288 MEDIA TESTING SCRIPT [2.0: Bionic update]
 
So here is the final release of the RK3288 media testing script. Basically, the script provides the following functionality:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@30 HEVC (the maximum supported by the SoC), and GLES 3.1 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi 18.0 alpha preview. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional small packages, that have no big interest from the developer prospective, but I find them interesting to play with: Support libraries for commercial web video streaming (tested with Netflix), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
Version 2.0 (Bionic):
 
Version 1.0 (Xenial):

>>> DOWNLOAD LINK (2.0, FOR BIONIC DESKTOP) <<<
 
> Older Download link (1.0, for Xenial) <
 
Instructions:
Download the file above Untar it: tar xvf media-rk3288_*.tar.xz cd media-script ./media-rk3288.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!
 
 
 

Ah @Hoerli
 
Check /etc/securetty
 
The console that you are trying to log in is probably unlisted.
 
\o Tony!!

I don't know if Microcenter is in Canada, but http://www.microcenter.com/product/475761/tinker_board_2gb

For what is worth, works great with my intentionally un-updated iPhone 6 iOS 9 
 
Edit: because... Old people are cranky!!! Get off my lawn slowing down my phone with new iOS, Apple!

https://invisioncommunity.com/news/product-updates/invision-community-43-r1055
 
I hope more bugs were fixed than added. 
 
Edit: well I already found a new one in the first post  Pasted URL has not changed to URL automatically at posting but at editing.

After fighting with this with a few distros..  I am close here:
 
1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) and:
 
make scripts
 
If that fails (classmap.h missing for example), there is a problem with the headers package.  You may need to manually edit scripts/Makefile and comment out the line with selinux -- there is a problem with the kernel config not matching the header deb in my case.
 
# subdir-$(CONFIGS_SECURITY_SELINUX) += selinux
 
2. From the same headers directory, verify that include/generated/utsrelease.h matches the full kernal name from: uname -a
 
- My headers (from beta repo) had 4.4.129 as utsrelease.h and 4.4.129-rk3328 as the kernel version/release.  This causes modules to be built incorrectly and their vermagic to not match--you can use modprobe --force to get around this, but ill-advised to use that for more than a quick test with something like zfs.  My utsrelease.h now reads: 4.4.129-rk3328
 
3. Edit /var/lib/dkms/spl/<yourversion>/source/configure and search for KUID, for lines that look like this:
 
kuid_t userid = KUIDGT_INIT(0);
kgid_t groupid = KGIDT_INIT(0);
 
Erase those two lines, the test itself is broken on our environments.  Leave the lines surrounding it.  These appear twice in the configure script--remove both sets.   
 
Now look for these lines:
 
kuid_t userid = 0;
kgid_t groupid = 0;
 
Change them to:
 
kuid_t userid;
kgid_t groupid;
 
(I filed a bug here https://github.com/zfsonlinux/spl/issues/653#issuecomment-333973785 )
 
Now you can run:
 
dkms build spl/<yourversion>
dkms install --force spl/<yourversion>
modprobe spl
# should be no errors here, check dmesg otherwise
 
dkms build zfs/<yourversion>
dkms install --force zfs/<yourversion>
 
When configure runs, you should now see:
checking whether kuid_t/kgid_t is available... yes; mandatory
 
Some notes:
 
- I ended up switching to beta (sources.d) and doing an update/upgrade/dist-upgrade first because there were no kernel headers for the WIP rock64 image I installed.
 
- If you use kernel 4.11.x you will need to use SPL/ZFS 0.7.x.  I am using the standard zfs-dkms/spl-dkms 0.6.5.9 packages for now..  install SPL and let it fail, then dkms install it after the steps above and then install the ZFS package.
 
Just started with Armbian today .. in retrospect it looks like it has drawn me in..
 

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Hi Board,
 
I have submitted a PR a few minutes ago to Build repo (https://github.com/armbian/build/pull/927) removing some drivers that WILL NOT load in RK3288, because they are specific to other SoCs / Architectures.
 
I also took the opportunity to convert a batch of drivers / machines to modules, in order to alleviate the kernel size and squeeze some performance (because some of the loaded stuffs does effectively consumes CPU). Well, that's what modules are meant for, right?
 
The patch was crafted to DEV version. Need more extensive Tinkerboard tests (did not test the GUI) and MiQi (not tested at all, I lack the hardware).
 
Have a great week,
 
- RF.

comes from this here:
 
https://github.com/TinkerBoard/debian_kernel/blob/12e65902b4fdcd5211e498ad72543891aebdf596/arch/arm/boot/dts/rk3288.dtsi#L212
vs. 
https://github.com/rockchip-linux/kernel/blob/2b3fe0f3500bd62ea6ba3a2da177edda27a8d6ea/arch/arm/boot/dts/rk3288.dtsi#L233
 
the RK kernel hasn't defined opp>1.6GHz....
You might adjust it, test if it runs stable and then use it.. This needs at least recompilation of the devicetree.. 

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

OpenSSL is user-space, so you need to use AF_ALG (or Cryptodev but that's kind of old-school) to bridge to kernel-space and access the rk_crypto driver.   I looked at this (referring to some Marvell pogo-plug era documentation) but never bothered to sort out all the pieces needed.  
 
My application was a VPN, and I went the easy way and used IPSec, which lives in kernel-space.  A good kernel module, StrongSwan, and the related NetworkManager plugin and you *should* be good to go.  But, like I mentioned in my post above:  with no module loaded, traffic flows fine.  With the module loaded, I got no traffic and usually  had a whole-board lockup.  
 
AFAIK, many of the v8 chips out now support ARM crypto acceleration so there's little point in mucking with something proprietary except out of curiosity.  
 
 
 

Hi again. I use this for motor controller.
https://www.aliexpress.com/item/2-DC-motor-drive-module-reversing-PWM-speed-dual-H-bridge-stepper-motor-Mini-victory-L298N/32733219776.html?spm=a2g0s.9042311.0.0.wQdo9D
It's the same pricipe as the l293d but they can handle a bit more power and they don't overheat that easily. Also there is an overheating protection.
You could use a heatsink on the L293D's, normally they dissipate heat via the solder joints, but you've breadboarded it so it can't do that.
 
Are you going to solder the L293d to a circuit board afterwards?
 
Don't be aftraid to use resistors. They are safe to use, but you need big enough resistors if you put thru a lot of energy. Christof explained a bit.
Watch a youtube video about it. There's two things you need to understand, Ohm(resistance) and Watt(power).
It might look confusing in the beginning, but you'll be happy to know.
Good luck. I love it seeing people do something like that.

I could put together a simplified equivalent cuircuit diagram for the web page to cover this sort of power confusion, since it is universal and based on very basic electrical concepts.

As for the instability concern: what are the cooling options being used? I have a large heatsink, and left off a Tinkerboard-only CPU throttling patch when the GPU was in use. I've never had instability, and given the Tinker does not have the worst cooling in the RK3288 world, assumed the patch was unnecessary (I also have the thermal throttle set to 80 instead 85 C).

I'm not ready to blame this strictly on the hardware just yet, unless it's possible your supply suffers from small "micro-break" events under heavy load. In this situation the device fails to provide stable power for some number of microseconds, potentially starving the board for power. I'll build a 4.4 kernel with the WZYY cpu/gpu patch for OP to evaluate.

Sent from my Pixel using Tapatalk

No problem! Rule #1: keep Youtubers happy 

Hello there Nico,
 
Use both RED pin headers. I mean, BOTH. Usual warnings here: Careful to not short with any other pins, use a high quality (properly filtered) and with at least 2 Amps power supply, etc.
 
There's a *lenghty* discussion here about $SUBJECT, look up posts from @TonyMac32. He even discusses how to build a good power supply.
 
Good luck :-)

Hello Nico
 
You could use a single header. But by using both, you have more 'copper surface' and less ohmic losses (read: voltage drop).
 
Connect GND to any black header and then you will be all set.
 
Best of luck :-)

Hello domoticity;
 
Odd. Have you checked the actual negotiated speed of your interface card (in the Tinkerboard)?
 
Looks like it is running in 100 Mbps instead. Check out my result:
 
[root@tinkerboard ~]# ethtool eth0 Settings for eth0: Supported ports: [ TP AUI BNC MII FIBRE ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s <======================== HERE Duplex: Full Port: MII PHYAD: 0 Transceiver: external Auto-negotiation: on Supports Wake-on: ug Wake-on: d Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes [root@tinkerboard ~]#  
Check your board result with # ethtool eth0 and let us know.
 
Ah. For what is worth, I have just finished a stress test here (I will replace the raspi with this tinkerboard) with netcat using the Tinkerboard both as the final destination (netcat running in the Tinkerboard) and NATting (using VLAN tag from two different VLANs).
 
I got effective routing throughput of ~ 930 Mbps from both up and downstream.
 
For completeness, this is a diagram of the test:
 
+-------------+ +-------------+ +--------------+ | Computer 1 | | Tinkerboard | | Computer 2 | | 172.16.3.1 | | | | 172.16.8.1 | +---+---------+ +------+------+ +------------+-+ | | | | eth0.3 | eth0.8 | Untagged VLAN 3 | VLAN 3 | VLAN 8 |Untagged VLAN 8 | 172.16.3.13 | 172.16.8.13 | | +-----------+----------------+ | | | | | +-------+ Switch +------+ | | +----------------------------+  
The tinkerboard is acting as a NAT / Gateway for VLAN 8. So we have here:
 
# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -I POSTROUTING -o eth0.3 -j MASQUERADE
 
So in Computer 1 I have:
# cat /dev/zero | nc -l 3333
 
In computer 2:
# nc 172.16.3.1 > /dev/null
 
Monitoring the traffic in Tinkerboard, using # iptraf-ng
 
This puts double penalty over the Tinkerboard. Instead of just routing, which is easy-peasy, it also does makes the Traffic pass through the Netfilter engine, and remember that I'm using VLAN tag, meaning the same physical inetraface servers both endpoints.
 
But wait, there's more: I'm using the Asus-provided heatsink (Tony will surely roll his eyes) with temperatures not  going above 56 Celsius.
 
Even with this scenario I managed to pull ~930 Mbps of effective NAT traffic.
 
The reverse is also true. Scenario:
 
Tinkerboard:
# iptables -t nat -I PREROUTING -p tcp --dport 4444 -j DNAT --to 172.16.8.1
 
Computer 2:
# cat /dev/zero | nc -l 4444
 
Computer 1:
# nc 172.16.8.13 4444
 
The second test is even more costly, because it has both the NAT and the Destination NAT.
 
Still ~930 Mbps.
 
<3'ing my tinkerboard!!!! \o/

Ah. Read the fancy manual :-)
./compile.sh KERNEL_KEEP_CONFIG=yes