jernej

Nothing readily available. Fortunatelly for you, there was some advancement in understanding secure boot last month (discussed on IRC and described on linux-sunxi wiki), but IIRC only for running signed images as opposed to encrpyted, which means that with proper knowledge eMMC can be resoldered to different board and dumped. As zador already said, saving key on same media as encrypted data is never a good idea. In this case, it would be best to save key in one time programmable memory located inside H3 (SID) and use secure boot at the same time, so only properly signed image can read decryption key. But there might be HW bug which makes bypass possible. Most knowledgeable people about this topic can be found on IRC #linux-sunxi at freenode.net. Please ask them for any definitive answers.

@Igor, you can try this: https://transfer.sh/CjnKx/u-boot-rockchip-miqi-sdcard.bin just flash it with 32KiB offset (or 64 sector as said by readme).

I couldn't make it work with 2017.03-rc3 and according to log, 2017.03 release doesn't change much. Try to use rockchip next repo or alternatively, use miqi-new branch from my u-boot repo. I'm also not sure if eMMC works properly. I have to recheck DT. As I said, early success

Hm, I never had to short resistor. First I invalidated eMMC bootloader using built in U-Boot command, so board always boots to special USB mode. Then I just played with flashing U-Boot with SPL to SD card... Which repo are you using for a base? I will provide compiled version later this day.

Fortunatelly, most cables/wirings are either OMTP or CTIA compliant. For that reason, I bought cheap OMTP to CTIA adapter from ebay, which solves many annoyances and now I don't need to worry anymore about pinout.

It seems that this method is already used: https://github.com/igorpecovnik/lib/commit/ba61ffe1011be5ab436856886ca7b55ab0c6f590

Do you use this procedure for flashing U-Boot?

Using latest u-boot-rockchip repo I managed to add MiQi support to U-Boot. Not everything is properly configured yet, but it should be able to boot kernel. @Igor now that SPL is working again, maybe we should go away from that binary blobs?

I think that KotCzarny from IRC (#linux-sunxi @ freenode) managed to boot Android (compiled by him) using mainline U-Boot. However, HDMI needed some special kernel command line option to be set in U-Boot in order to work. I'm not sure if just any Android version would work. Additionally, you would need HDMI patches for U-Boot and enable boot selection user interface in build config file. It is doable but not something I would like to spent time on.

So, did you manage to compile the modules?

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

@Igor, Is this variable constructed during script parsing? To be honest, I didn't played with it, but if I understand everything correctly, it must be available during initialization, which means that the only possible way is to save it as an environment variable - first setenv then saveenv and reboot. Video driver is initialized before boot script gets executed.

Please excuse my rant: Now I will deviate from my standard behaviour and I will provide step by step overview: 1. Figure out which symbols needs to be enabled: line 35 and 36 tells you that you have to add this to the config file: CONFIG_LIRC_GPIO=m CONFIG_LIRC_SUNXI_RAW=m Note that "m" means as a module, which will produce two .ko files. 2. Figure out if dependencies are satisfied: line 11 and line 19 gives you following dependencies: LIRC GPIOLIB Quick search trought sun8i kernel config file suggest that those options are already enabled here and here. 3. Start compiling and hope for the best. 4. When finished, search for lirc_gpio.ko and sunxi-lirc.ko. Note 1: You must set "m" or else driver will be embedded in kernel binary and there will not be separate .ko files. Note 2: I'm not completely sure how armbian build system handles the files. It is much better to use configuration through user interface as you already tried. Those options should be under "drivers/staging/media" menu. Every link is a pointer where I found the information and I didn't include exhaustive explanation of my last suggestion, because it is just check if everything went as planned.

Strange, what is the resolution reported by Linux? Does resolution detection works properly on any other screen? To answer your initial question, there is no way to change resolution the only way to change resolution is by creating special U-Boot variable, because the current driver is meant to be quick workaround until proper Linux driver is written. Current driver just ask monitor what is its prefered resolution (in your case it should be 800x480) and then sets it. Probably your lvds to hdmi converter doesn't report correct resolution. Anyway, according to adafruit page you linked, your monitor should work regardless, but I guess that you get weird scaled image as explained there? According to this page, this boards often have broken EDID data, which would explain the issue, but I would think that adafruit checks that before shipping. P.S. I just remembered, if you have 1024x768 resolution set, then this means that EDID data could not be read. Fortunately, converter could be reprogrammed...

Resolution is currently set by U-Boot. It reads recommended resolution from EDID. So, if the screen reports right resolution, it should work automaticly. Please describe your troubles more in details. Also the name of you display gives only the LCD panel datasheet. What kind of hdmi to lvds adapter do you use? Is it properly configured, especially EDID?

Just check if .config file in kernel's build folder has all required symbols enabled.

uh, sorry, for .ko you must set to "m", not "y". Former will produce module and the later it will embed driver into kernel.

In first post you said you applied the patch, e.g. copied it in right folder. What I linked is specific line in that patch (line 11, orange color if you use link above), which tells you what you have to enable before you can enable new functionality, e.g. on which kernel functionalities driver depends.

Ok, that was not what I expected. I thought that at some point there was patch for mainline RTL wifi driver which added SDIO IDs and maybe few other things. I wonder if that would work or not, but it would take some time before I can test this theory. After all, it would be unproductive for Realtek to always completely redesign the chips.

Are you actually capable of downloading patches? I'm not. Were his patches at one point used by Armbian?

This line gives you dependencies, which must be also enabled in order to be able to compile that (assuming patch is compatible with kernel source).

You didn't compile the drivers, because you didn't enable them in kernel config file. You need this: CONFIG_LIRC_GPIO=y CONFIG_LIRC_SUNXI_RAW=y

IIRC Jeff Moine had some patches for wifi as well. Unfortunately, I didn't save his patches before he deleted them. Does anybody have his patches?

That patch is only for legacy kernel. I don't think anyone bothered to make similar patch for mainline kernel. Don't get me wrong, it is not trivial, some kernel knowledge is required.

I'm pretty sure that both of your assumptions are correct. A lot of SoCs have special buffer for mouse pointer which get blended a top of everything else. I'm pretty sure that's the case here too. IIRC I heard that RK3288 supports 1080p max and 4K is just upscaled version of that. About other issues - MiQi board with same SoC has definetly working GPU and VPU drivers, so I think this is only temporary issue.