jkljkl1197

I think I messed in one or two attempts with it before I gave up...  It failed everytime on build if I've this right in mind..  
This might help you:
 
 
 
have fun.   I lost a bit track on it.. due to dealing with other crap..  in case you want to compare:
the output of make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rockchip_linux_defconfig is attached bellow.. 
rockchip_orig.config

I've picked up both the 5 MP and 8 MP camera module, we'll see if I can help.  If not I have a pile of Pi's lying about gathering dust...

Since Armbian moved to the official Rockchip kernel, camera support should work with their new ISP1 driver. I built an image with the needed drivers but unfortunately it doesn't boot anymore...  
A boot log with the compiled drivers can be seen here (kernel config is attached to this post):
What I tried so far:
-disable all patches which have something todo with MIPI system and adjust defconfig
-try to compile kernel with isp1 as module (doesn't compile)
-the 'asus way' of getting the camera to work seems also not possible (thanks to @TonyMac32 for providing those links). Please consider that they don't use the same kernelsource.
The 'asus way':
https://github.com/TinkerBoard/debian_kernel/commit/159704c50bc8b6ea5cdc312a2425aa85ddb4c19e
https://github.com/TinkerBoard/debian_kernel/commit/5ba2b36a2f6a419088f2482fbf955228ce36ebb6
https://github.com/TinkerBoard/debian_kernel/commit/24ef89c0d19b4bc8251c24207f25b0e3cb96c497
https://github.com/TinkerBoard/debian_kernel/commit/c2b6426fed813cf668f8ac272dba0f7714115647
(it's possible that I did a mistake here, cause there are so many changes that I might miss something...  )
 
To my knowledge there's no linux available for the tinker which uses the new ISP1 driver for camera support. Any help/idea/hint for getting up the camera support is appreciated. 
linux-rockchip-default.config

OK, development branch will reflect the change, on existing installations you will have to manually add
console=ttyS3,115200n8 to the armbianEnv.txt file in /boot.  I did a tiny bit of house cleaning as well, putting the Tinker u-boot patches into a board-specific directory so they don't impact the MiQi.

I will be testing this change tonight or tomorrow, it was put on hold because it presented problems for the MiQi, but I since learned I can make per-board U-boot patches.  I will update here on completion.

Good catch.  It could be because only Uart1 has cts/rts from what I can tell, and that might be needed somewhere besides a terminal...
 
Hey, that was me! 

no, that's the original.. and actually also present in ours, cause we don't install the needed drivers, it is (at the moment) useless. In case you go for the OV5647 camera, you have to change it to something like: 
camera0: ov5647@36 { compatible = "ovti,ov5647"; reg = <0x36>; clocks = <&ext_cam_clk>; status = "okay"; port { imx219_out: endpoint { remote-endpoint = <&imx219_in>; data-lanes = <1 2>; }; }; }; camera1: imx219@10 { compatible = "sony,imx219"; reg = <0x10>; clocks = <&ext_cam_clk>; status = "okay"; }; Cause the port names in the rest of the DTS (where those ports end) are named imx219.. this should work... Actually a proper naming like camera_out would end in less confusion.. 

camera0: ov5647@36 { compatible = "ovti,ov5647"; reg = <0x36>; clocks = <&ext_cam_clk>; status = "okay"; }; camera1: imx219@10 { compatible = "sony,imx219"; reg = <0x10>; clocks = <&ext_cam_clk>; status = "okay"; port { imx219_out: endpoint { remote-endpoint = <&imx219_in>; data-lanes = <1 2>; }; }; }; huh? both are status okay, but since cam0 has no endnode it will never run out of the box..  So cam1 (which means imx219) is the one looks complete and active.. Or do I miss something?  

I'm guessing you need to use an overlay, the other camera is enabled by default.

not with the IMX219, just gave it a short try after weeks of just ignoring it..  It still hangs in oops during boot.. And since I'm to dump build booting images with RKs buildscript... No clue if it's broken at all, or that I'm just to dump.. If someone builds a recent booting Image with their buildscript please post the actual config (not the one I get from the kernel, that's what I can do on my own..  )... 
 
not with the config we use at the moment, since activating the needed drives will end in not booting images anymore... Even if the camera is not connected.. In case you start to dive into it.. Which cam will you use? Just have a look to the github issue to avoid you doing common mistakes.. I don't have this image anymore to test it with the imx219, but as for my ov5647 I never got it working on their own image. So, I never saw a tinkerboard with their new isp1 driver and a working camera. But maybe, it needs some fresh mind working on it, since I might be to dump and miss something obvious.  
 
As said before.. Everything is there, it's just a thing to figure out what's going wrong..  You can start to build images on your own and try to figure it out. 

The Tinker OS kernel is using a now deprecated driver, As we're using the Rockchip kernel directly, we should work to the new driver, which requires *a lot* less "tweaking" to work.  In short, I haven't had the time to get this working, what with actual bugs on the table to deal with.  Like I said, I'll give it another go shortly.  There were some adjustments to the drivers, so we'll see.

It should be plug and play. It works on ASUS images (https://tinkerboarding.co.uk/wiki/index.php?title=CSI-camera). But there is some bug that is preventing it from working in Armbian. It might have gotten fixed already, you can try it and see if it works.
(What I mean is that there has been a patchset applied recently in the development default image, that may have fixed the bug. But I have been the whole day trying to find my Rpi camera, without success, so I couldn't test it).

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! ;-)

Alright, I think I got something working !
 
MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image !
However, I only tested this with 1m30s sample files so I'll have to test this more seriously.
 
Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers !
 
So here's a patched kernel build, including the VPU driver in it :
https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test
 
This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise.
 
Here's the repository containing the patches applied :
https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests
 
And here's the patch itself :
https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch
 
Here's the repository containing the working VPU code :
https://github.com/Miouyouyou/rockchip-vcodec/tree/retry
 
 
 
Testing the VPU
 
Now, in order to test the VPU driver, you'll need something that work with it !
I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface.
https://github.com/rockchip-linux/mpp
https://github.com/LongChair/mpv
https://github.com/rockchip-linux/libmali/
 
Have fun !
 
Whether everything works or you got a crash, don't hesitate to reply on this thread.
If you something went wrong, please provide any crash message that might appear in dmesg !

Not yet.  There was just an update to the kernel, looks like some driver work went on, might give it another go shortly.

thx @NicoD. yeah maybe later after adding resistor and complete the circuit i am going to use a circuit board.
 Ho yeah it's change something.

That'll teach me to do math after a dose of Norval - of course you're right.

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.

5V with a 1R load is 5A, 25W
5V with a 0.5R loan is 10A and 50W
 
For a 2A load on 5.1V, the calculation is 5.1/2 = 2.55 ohms

Now I understand, I thought you wanted to use your Tinker in your car. Cool what you've done, for that I also use a power bank. Here a video of me building a simple robot with an Arduino. Keep up the good work. Sorry for the misunderstanding.
 

If you truly want to do it yourself with battery's. Then don't forget to use a good loadcircuit. Or your guaranteed burn your car down.
I still advice to use a good power bank, it's got a loadcircuit and power management.
But do as you wish, but be safe.

Two 4V 2.6AH batteries in series, connected the input of the 4015. Output goes to GPIO, use at least two ground and two hot pins.  Before connecting set the 4015 to output 5.1V with a 1 ohm, 10 watt resistor across the output terminals. If you have a big enough resistor (20w at least), use 0.47-0.5 to simulate a 2 amp current draw. You can get 2+ hours out of this at full load, more at reduced draw. **Edit - this math is wrong, was corrected few posts below***
 
Remove your dummy load and hook up the Asus. I use a powerbank with a Little Pi Zero as a portable media player and headphone amp (not using Armbian for this). Powerbanks are usually quite variable in quality, so you might get a lemon. The 4015 is at least reliable.

I have used it with the Tinker Board. But I more often use it with my Odroid C2. I've got a self made laptop with that battery, a 7inch 1024*600 display and a Rii i8 keyboard. Very handy. This battery can power 2 sbc's and the screen at the same time.
The Tinker Board does use more power, so you could choose the other 22000mAh type. That one can give 2.4A per port and 5.8A overal.

Yes, use something like this.
https://www.ravpower.com/26800mah-external-battery-charger-iSmart2.0-black.html
You can charge it in your car with a car-phone charger. It lasts for 10 hours. An has voltage regulation installed.
Looks like too much hassle to make it yourself when it's easy to buy it.
Greetings

it's everything there to try it on your own..   
 
I decided that I need a break from the tinker cam cause it's frustrating to get oop as a first boot message..  Since my buildmachine is only limited usable. I build on a old desktop machine which doesn't have a screen and everything is through ssh --> copying to my notebook prior to flashing it to SD-Card (wifi card is broken, and the stick which is attached to it performs very bad), I'm not that motivated to build as much images as possible to nail down the problem. And I'm not experienced enough to figure out the problems without a 'try and error' approach..  So any help and findings what might help is appreciated..