jernej

4.4 kernel should support it since last month or something like that (I was analyzing exactly that piece of the code), but I didn't test it.

Seems so. Compare this and this. Pick a place to fix it.
 
Please note that TV out is not included in this patch. I will add it when I will have time.
 
P.S.: It looks like this driver will be in next U-Boot release. Unfortunately, I can't say the same for fixes I sent later (they go in through different repo).

Yes, I know. This was because DE2 itself needs DM_I2C to be enabled (not really, just to prevent warnings), so I had to do some intermediate patches which was ready few days after clocks were merged. However, pull to master for rc3 was done in between those few days when I was preparing DM_I2C patches... Now I'm really not sure if DE2 will be merged or not. One week chance

At least here is the (temporary) solution for simplefb:
https://github.com/Icenowy/u-boot/commit/315edb971fa05d80fd0f17190406125f7455dc96

I have reworked ffmpeg's cedrus264 encoder to use libcedrus and modified libcedrus to allow few clients to use VE (in the same process).
How it is possible to use both vdpau-sunxi decoder and cedrus264 encoder to transcode the video.
The results for
./ffmpeg -hwaccel vdpau -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -pix_fmt nv12 -r 5 -an -b:v 64k -c:v cedrus264 stream.mp4 are the following:
Video is viewable, CPU usage is ~80-90%, FPS while encoding ~6.7, time real 0m56.523s, user 0m28.210s, sys 0m15.720s
It is not as good as I was expecting though. Perhaps, copying data in memory is a bottleneck.
Not sure it could be improved
 
The code is located at https://github.com/divis1969/libcedrus (branch master) and https://github.com/divis1969/FFmpeg (branch 2.8-cedrus)

You can't, yet. SimpleFB driver used for now doesn't support anything besides simple framebuffer. Actually, framebuffer is set up by U-Boot and Linux knows only where in memory is located and how big it is, that's all.
 
Proper HDMI driver is in the work by me (already written, but not yet functional, I have to fix all the issues first), which will allow to do all that.

First Rockchip RK3399 based board from Orangepi maker - under development, not much news except what can be scrapped from pictures. Chip: http://rockchip.wikidot.com/rk3399
 
 

PC+ was made before NAND started rapidly increasing in price.

@tkaiser you mean this commit https://github.com/jernejsk/OpenELEC-OPi2/commit/3de7bcdf1adc3886938d2b0220c9e30203a1ef0e ? It doesn't have any detailed message, but IIRC I commented somewhere, probably on github.
 
Anyway, if that parameter has a value, then USB gets probed. Because I changed how the kernel behaves - wifi is always powered on at boot to enable autodetection, this mechanism became redundant and even it could cause troubles, so I disabled it. Of course, wifi driver has to be patched too, where probably issue lies. That's way I added another patch which solves loading rtl8188eu driver: https://github.com/jernejsk/OpenELEC-OPi2/commit/85205e9449a4ff65c967101fbbc736a456afbf2d

No need to depend on board maker support, because official Rockchip version should work pretty well and basically all drivers are mainlined anyway.
 
Yes, it is possible, but I'm not sure how easy or interesting it is. If it is based on reference design, then yes, it is matter of hours for some who knows DT stuff. Another issue is how hard to find or extract is manufacturer dtb file. I doubt that they provide schematic. It is also the question if it is worth the effort.
 
I guess it should be similar enough to some existing board which has support already manilined. The biggest difference between the boards I saw is which power management chip is used.

Don't worry, mali driver is built as a module, so unless you load it, it won't eat any resources, except a bit of a SD card storage.

More precisely, MIPI DSI connector, because that is the only type of LCD connector left if you implemet gigabit ethernet.

Don't worry, mali driver is built as a module, so unless you load it, it won't eat any resources, except a bit of a SD card storage.

Ok, found the issue. Apply this patch a top of previous: http://sprunge.us/KETE
 
It seems that H3 TV works without calibration, but H5 doesn't. Fortunatelly, it work with fixed value for calibration.

- fixed eMMC install, - added development kernel (4.10.x) with MALI driver (untested)   Onboard 16GB eMMC media performances - not the top performer but still very decent.
root@miqi: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 2403 2503 12483 12840 10950 2400 102400 16 8277 8682 26678 26378 24787 8526 102400 512 26729 27105 40906 40921 40702 27001 102400 1024 27644 27575 41840 41808 41731 27562 102400 16384 28077 28056 43618 43609 43589 28147

I finished with hammering old code: https://github.com/jernejsk/u-boot/commits/de2_wip
 
Now it should support also A64. Please keep in mind that this is based on latest u-boot master branch. Because of that, I added AXP patch for A64 which might conflict with ATF code (not sure anymore). Above branch was tested on H3 and A64. I thought that H5 support was already mainlined, so I put also H5 defines, but obviously it is not. Feel free to try it on some apritzel branch. I think it should work without any code changes.

MiQi added to Armbian. What I did:
 
- added kernel 4.4.50 ... took from https://github.com/mqmaker/linux-rockchip(4.4.16) ... and patch all the way up to 4.4.50. 
- added stock MiQi uboot. I tried too merge it with mainline but figured out soon that it's not going to be easy and abandoned that
- added boot scripts with environment file
- packaged kernel, u-boot, ...
- updated kernel config to meet Docker requirements 
- added proper serial console
- tested CLI and desktop build. Both runs smoothly.
Known bugs: random MAC, eMMC install script and boot script need some adjustments
 
Unknown: mali, video accleration librarires, ... etc. most likely those should go: https://github.com/mqmaker/rk-rootfs-build
 
From tomorrow morning, betas will be available here: https://dl.armbian.com/miqi/nightly/
 
armbianmonitor -u
http://sprunge.us/TWMF

Console log:
 
 

Ok, but not today. I will report here when done.

Found it!!!
 
If I put this in composer init, it works!
 
u32* syscon_reg = (u32*) 0x01c00004;
clrbits_le32(syscon_reg, 1 << 24);

Legacy with disabled display (for SD): u-boot-with-dtb.zip
 
Mainline with boot0 is more tricky (needs more time), will try to make it tomorrow.

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

Basically I tested it only on OPi2 and there it works nicely. If HDMI screen is connected, then HDMI is used, otherwise TV out is enabled. The only possible drawback I see is that TV out detection is not implemented and it unconditionaly enables it if HDMI is not connected. This is the same behaviour as in video driver for older chips.
 
Small note, I updated the driver and simplefb node in DT for TV out must have a different name "de0-lcd1-tve0". Reason for that is that TV out has different clocks, which get disabled at shutdown - DE2, TCON1 and TVE0.
 
Now, I will try to make it work on A64.

@zador,
 
I just added support for TV out, PAL and NTSC standard. Do you think that it is interesting enough to include in Armbian? Maybe for OPi0?
 
https://github.com/jernejsk/u-boot/tree/h3_hdmi_tv_v1
 
You have to include "CONFIG_VIDEO_COMPOSITE=y" in defconfig. PAL is selected by default and can be overriden by environment variable.

If I understand you correctly, you didn't try it yet? Because the driver should select native screen resolution, in this case 1080p. If it is not, then it is bug.
 
 
 
H5 doesn't have any HW 2D acceleration, only 3D through mali.
 
 
For this you need DRM driver. Maybe something can be done with H3 experimental one, but let's focus on basics first.

I got my hands on some files of r6p2 driver and LibMali.so if anyone is interested:
 
https://github.com/mosajjal/r6p2