jernej

I will get two MiQi boards and I will try to make preliminary Armbian support.

I will get two MiQi boards and I will try to make preliminary Armbian support.

I checked datasheet and board schematic and only setting possible is to select polarity. For any permanent disabling, HW solution must be used.

Instead, we were rewarded. Not many got this privilege.
 
 
 
https://distrowatch.com/weekly.php?issue=20170116#donation

As I promised, I published helper tool. Please check this comment: https://github.com/igorpecovnik/lib/issues/594#issuecomment-272992961

I bough RK3299 at one point for hacking. Unfortunatelly, I can't find any SDK. Does anyone now where to find it?
 
On the other hand, I'm more and more interested in RK3288 based boards. Support for that chip should be pretty good in mainline kernel. If someone know cheap board (max. 50 USD), please tell me. I think I could find some time to add support for it.

Of course it works. And was working fine since the very beginning. You can find the detailed step by step instructions here: https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool
 
Please note that the flashrom method is not very foolproof. The sunxi-fel tool may provide some nice high level features in the future. Such as the installed bootloader identification, extra checks if the old and new u-boot configurations are compatible, SPI speed tuning for faster boot (right now it is working at 6MHz in U-Boot) and maybe even larger SPL sizes via an additional loader stub. Not to mention that U-Boot may enforce write-protection for itself before passing control to the linux kernel (write-protection is enforced until the next power-down/power-up cycle), and in this case the flashrom tool will become completely useless.

I think the best way is to ask monitor what timings it prefers. That way you can be sure to use best possible combination. As soon as I will have some time I will prepare something as described here:
https://github.com/igorpecovnik/lib/issues/594

Default Armbian configuration file forces HW decoding, so it needs to be explicitly disabled or config file should be temporarily renamed.

Why people every time think on worst possible option? It is more likely that they just forget to disable some clocks for some HW units which still run and eat power.

@zador,
maybe a multimedia subsection should be made with a big red warning saying "GPU doesn't decode video" with the link to http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
 
This is most detailed description I could find in datasheet:
 
 
Obviously, 10 bit HEVC is not mentioned anywhere. Of course they might just forget to state it, but until I see working 10 bit decoding, I will claim that HW acceleration of 10 bit HEVC is not possible. I'm not sure if CPU is fast enough to do it in SW.
 
@hojnikb,
maybe because they wanted to join 64 bit ARM hype? Easy, take H3 and change 32 bit core with 64 bit, update Mali cores and you are done. As you may noticed, sales are fuelled with marketing bullshit instead of common sense.

Be aware that GPIO pin is capable sourcing only about 20 mA of current which is waaaaay too low for running any kind of motor. You need to put some kind of transistor in betweeen, like MOSFET. You have plenty tutorials on the net.

I will update audio drivers from tinaos, which improves I2S (reported in another thread). Based on the fact that HDMI also uses I2S internally, I hope this will improve situation. From what I know, tinaos and H5 BSP codebases are not very far apart.

Yes, there are at least two - No HDMI documentation and no or GPL incompatible license for HDMI code in BSP kernel.

Ok, I will try to make something next week.

Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590
 

Little bug here. You rounded to commonly used 148.5 MHz, which also might be fine, however, in this case you have to change pll_video to 297 (148.5 * 2 = 297). Another, originally recommended, option would be to use 147000000 Hz (lesser error) and pll_video set to 294 (as it is now).

No, 297 is default value and the only correct one for 1080p

yes, it has same or better functionality and it must be present anyway (pinctrl) if you want to have useful kernel.

GPIO sysfs interface should be the same on both, mainline and BSP, kernels. I checked that a month or so back. I think the only work which needs to be done here is identifying differences between the boards and implement this in a sane way.

GPIO sysfs interface should be the same on both, mainline and BSP, kernels. I checked that a month or so back. I think the only work which needs to be done here is identifying differences between the boards and implement this in a sane way.

serial console, ssh, wherever you have access to the console... You can also add command to load it at boot, but for that you still have to have access to some kind of console.
 
@igor,
maybe you can make tv driver built-in? Seems that this is common issue and mostly chicken - egg problem if user has fresh image without access to the serial console and hdmi monitor.

https://github.com/NextThingCo/chip-mali-userspace/blob/master/debian/copyright

I just learned on U-Boot HDMI driver example that kernel implementation is not complete. Most importantly, it is missing code for changing PLL_VIDEO clock, which is important code for supporting otherwise non suported resolutions.

I just learned on U-Boot HDMI driver example that kernel implementation is not complete. Most importantly, it is missing code for changing PLL_VIDEO clock, which is important code for supporting otherwise non suported resolutions.