TonyMac32

Okay im not gonna lie...that makes me pretty excited..    i cant believe im saying this but id gladly admin jira.
 
I have it running in my nomad cluster on one of my opis.  (I dont recommend such insanity btw)

@Myy I missed your comment on the initial commit, I need to quite waiting until midnight to do the more interesting stuff. 
 
I'm being presented with 5 options under the rockchip_mpp kconfig:  I've got MPP_VDEC_DEVICE, vpu decovder V1 and V2, vpu encoder V1 and V2. Are they all needed?

Pssssst:
 

 
So, this has @Myy's work with the patchset that got dropped on the mailing list for vdec, I've gotten everything building properly (minus a wireless driver and we don't have 1.7 and 1.8 GHz opps)
 
I ran the media script ans installed everything.
 
I'm watching a 1080p mp4 at fullscreen, here is my armbianmonitor -m:
 
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 05:41:25: 1608MHz 1.00 20% 3% 16% 0% 0% 0% 51.7°C 0/11 05:41:30: 1608MHz 0.92 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:35: 1608MHz 0.92 21% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:40: 1608MHz 0.93 19% 3% 15% 0% 0% 0% 51.2°C 0/11 05:41:45: 1608MHz 0.93 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:50: 1608MHz 0.94 21% 5% 16% 0% 0% 0% 51.7°C 0/11 http://ix.io/1zbd
 
As for functionality, gstreamer does not seem to want to work, so I would guess the vdec isn't operational yet, or something isn't quite right.  In any case, there is hope, perhaps.  ;-)

Pssssst:
 

 
So, this has @Myy's work with the patchset that got dropped on the mailing list for vdec, I've gotten everything building properly (minus a wireless driver and we don't have 1.7 and 1.8 GHz opps)
 
I ran the media script ans installed everything.
 
I'm watching a 1080p mp4 at fullscreen, here is my armbianmonitor -m:
 
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 05:41:25: 1608MHz 1.00 20% 3% 16% 0% 0% 0% 51.7°C 0/11 05:41:30: 1608MHz 0.92 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:35: 1608MHz 0.92 21% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:40: 1608MHz 0.93 19% 3% 15% 0% 0% 0% 51.2°C 0/11 05:41:45: 1608MHz 0.93 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:50: 1608MHz 0.94 21% 5% 16% 0% 0% 0% 51.7°C 0/11 http://ix.io/1zbd
 
As for functionality, gstreamer does not seem to want to work, so I would guess the vdec isn't operational yet, or something isn't quite right.  In any case, there is hope, perhaps.  ;-)

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise.  The compromise is reduced with more active participation all around. 
 
Now, who is participating?  
 
-Vendors: Almost every vendor has some software team, or they pay for one.  They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware)
 
-Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc.
 
-Users: buy the board, try our software, ask for/provide help from/to others.  Very important for a project, a bit lacking here.  Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day.
 
Targeting a group in this requires time of its own, but honestly we need the feet on the ground.  It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues.  I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board".  A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. 
 
For other issues that have been a gnawing problem:
 
Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ .  Etc.

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise.  The compromise is reduced with more active participation all around. 
 
Now, who is participating?  
 
-Vendors: Almost every vendor has some software team, or they pay for one.  They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware)
 
-Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc.
 
-Users: buy the board, try our software, ask for/provide help from/to others.  Very important for a project, a bit lacking here.  Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day.
 
Targeting a group in this requires time of its own, but honestly we need the feet on the ground.  It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues.  I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board".  A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. 
 
For other issues that have been a gnawing problem:
 
Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ .  Etc.

!!!  We use Jira at my day job...  interesting

Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
 
First off, same nice packaging the Tinker owners are familiar with:
                         
 
The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
 
The reason for the weight becomes immediately obvious when pulling the two halves apart:

All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
 
Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
 
I can't verify (no hardware), but the holes are 85mm apart and threaded.
 
Board fits nicely:
                                 
 
Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
 

 
 
 
My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.

As I noted earlier,  I had problems with usb storage not being recognzed on a rock64 after  update to the 4.20 kernel.  In my case on a Rock64 v2.0 , I seemed to have fixed the problem  by making the following changes which are reversions to the previous 4.19 dts values.    
 
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {#############################  from 4.20,  changed A2 back to D3  to make things work
compatible = "regulator-fixed";
enable-active-high;
gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;




usb2 {
usb20_host_drv: usb20-host-drv {
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;#################  from 4.20,  changed A2 back to D3  to make things work

My board is version 2.0

This problem did not affect other usb devices, btw,  just storage...  I tried to check the specs but didn't see find anything for vcc_host1_5v ,  vcc_otg_5v or usb20_host_drv.

I did find usb_otg_drv at A2.....   
 
I noted the aobe in the pine64rock64 forum,  but have had no response their yet.  I am now back to booting off of a ssd on USB3 and having a usb stick and mouse/mouse keyboard on the usb2  ports--  once again,  this is on a Rock64 v2.0

Any 3.3 V level UART USB dongle will do the job (for the C0/C1/C1+/C2), you can even use standard breadboard female cables to connect to the Odroid serial console pins:

Okay, the driver is loading now... So now, I have to pull out a setup that can use "mpp service"... @JMCC Is your setup useable with MPP service ?
 
I'll try to rewrite the patches and upload them, along with a complete build, in order to let people play with it, see if they can get something out of it.
 
There's still a *BIG* fat warning : [    6.565010] Failed to attached device ff9a0000.video-codec to IOMMU_mapping
Now... The nodes have been split in two and ff9a0000.video-codec is the Video Encoder. The Video decoder is at ff9a0400.video-codec so... maybe it's working fine ?
It's still highly probable that it will just crash in a very bad way.
 
Anyway, I'll need some testers that are used to the whole MPP stuff.

The text all looked fine to me, unless you mean you're still working on the definitions of tasks.

Why not?
 

Well, Oshpark turned around my order in 5 days, so I was able to build one today:
 

 
So far no problems, 5.16 V open circuit voltage, nominal design intent was 5.20, so within tolerance.

Well, Oshpark turned around my order in 5 days, so I was able to build one today:
 

 
So far no problems, 5.16 V open circuit voltage, nominal design intent was 5.20, so within tolerance.

ok so i think i should update as the issue is now resolved. the nic is dead (hardware issue)  
i contacted ASUS in america (I am from the UK) who, after troubleshooting, decided that it needed repairing. and was willing to do this if i sent the board to them but as i am from the uk they referred me to the uk site with a reference number of what was going to take place.
ASUS Uk would not help me saying "they would not accept return of this item to be repaired even though there is a 24 months warranty. ASUS USA would allow it they stated that each country has a different returns policy, i would need to contact the suppler. luckily enough it was amazon who when i contacted them said we will send a new one out and would arrive tomorrow! WOW i dont really like evil corporations but F**k that was fast. so i have the new board and everything works fine and a happy ever after................
 
Thank you all, for helping me out in my time of need.

I can confirm that latest armbian with next kernel (4.19) on rk3288 works flawlessy with prolific USB-to-serial adapters:
15567.072909] usb 2-1: new full-speed USB device number 2 using dwc2 [15567.281604] usb 2-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 [15567.281616] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15567.281623] usb 2-1: Product: USB-Serial Controller [15567.281630] usb 2-1: Manufacturer: Prolific Technology Inc. [15567.318362] usbcore: registered new interface driver pl2303 [15567.323408] usbserial: USB Serial support registered for pl2303 [15567.323550] pl2303 2-1:1.0: pl2303 converter detected [15567.327312] usb 2-1: pl2303 converter now attached to ttyUSB0 I use it daily with Arduino IDE to develop and push things to ESP8266 and works without issues.

Aha, I got it. We were missing the firmware.
 
Here is the output of mpv. Notice the line confirming the use of hardware decoding:
 
Here is a ffmpeg output:
 
Though, performance is far from being good yet. Let's see if I can find some time to package everything I have so far into a script, for others to test too.
 
I'm attaching the firmware here. @Igor I'm going to add it to the armbian/firmware repo.
meson-firmware.tgz

the new one has 2, and a big inductor that looks like a small office building.  
 
Yes, all of my components sit on the "top", other than the header to connect to the other board.  
 
 
I've taken to using a hot plate with thick steel "heat diffuser" to keep the surface consistent, I don't get any charring that way, the only tricky part is removing boards to cool them acceptably, but I've more or less worked that out, and the hot plate was $25.  I will admit SMT is new for me (I hand soldered the boards in this thread, for instance), but so far I'm having decent success.

Some feedback from @chwe and some improvements on the protection circuitry:
 

 
And for the record, electrical cleaner can/will dissolve your electrical connectors...   Also, lead-free solder is an angry and terrible thing.  ;-)
 
I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...  

Some feedback from @chwe and some improvements on the protection circuitry:
 

 
And for the record, electrical cleaner can/will dissolve your electrical connectors...   Also, lead-free solder is an angry and terrible thing.  ;-)
 
I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...  

Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
 
First off, same nice packaging the Tinker owners are familiar with:
                         
 
The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
 
The reason for the weight becomes immediately obvious when pulling the two halves apart:

All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
 
Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
 
I can't verify (no hardware), but the holes are 85mm apart and threaded.
 
Board fits nicely:
                                 
 
Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
 

 
 
 
My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.

Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
 
First off, same nice packaging the Tinker owners are familiar with:
                         
 
The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
 
The reason for the weight becomes immediately obvious when pulling the two halves apart:

All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
 
Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
 
I can't verify (no hardware), but the holes are 85mm apart and threaded.
 
Board fits nicely:
                                 
 
Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
 

 
 
 
My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.

I fixed some u-boot bug, happening in boards with 1GB of RAM, that could not load u-boot. Here is the console log with the failure:
Reference to the commit: https://github.com/armbian/build/commit/01571c0a4c6c3e7cdb1fec8c99465d8fc00c8c90

you are my hero tonight.  my cluster is running again. i can go back to sleep now..