jernej

@tkaiser, there is really no point in using CedarX binary libraries. You could extract them and that's about it, because none of the standard video players know how to use it. Much better approach would be to use libvdpau-sunxi. That way, any player, which knows how to use VDPAU API, should work and it's open source EDIT: About HDMI audio patch - As far as I can see, almost all changes are already included, namely setting max number of channels to 8. Probably something can be improved by looking at A64 kernel source and porting changes over.

I'm not sure how much porting all fixes and improvements would help. Display Engine and HDMI controller HW are not the same as on A10 and A20. EDID improvements would help only with automatic selection of most appropriate mode for attached monitor and not adding special mode for it as far as I understand. Even HDMI driver for mainline kernel was not accepted because people didn't know what exactly driver is doing and problematic copyright issues. Actually, there is no documentation about HDMI controller on H3. So any modification you do to support additional mode is educated guess at best. Correct me if I'm wrong, but I afraid I'm not. BTW: Actually it is better to add modes, not modify them. This way we can be sure that we are at least compatible with other images.

Setting CONFIG_FW_LOADER_USER_HELPER should not be selected. You want kernel FW loading support, not userspace. Probably the patch would be applied cleanly if it would be applied right after updates to 3.4.110.

Kernel is missing support for loading firmware directly. Patch is needed for that, because newer versions of systemd doesn't support that functionality. Will do, but not before sunday evening I'm afraid. I have some limited knowledge of DT, because I tried to enable leds in mainline U-Boot This feature is a bit harder in U-Boot but should be easy in mainline kernel. I can try sometime next week if you want.

Ok, I didn't try this systematically. Most probably everything is ok now that I think about it. PG11 pin is used on every board except on OPi2 where is unused and it is safe to toggle it. On Plus it is for enabling SATA & USB, on PC and One it is for enabling CSI port. At least I think it is and I love unified things About "noram" and CMA: I tried hard to solve this issue, especially because on Armbian everything was ok but not on OpenELEC. I come to the point that I set every thing in kernel that is set for Armbian, even if it was suboptimal. Issue was still there. After that I realized that issue is somewhere else. First I thought about initramfs, but then I figured out that it is not in the CMA controlled RAM region. At the end, I remembered that OpenELEC has some switches which are passed via kernel command line. You can check here what this means. Basically it changes the way how root filesystem is mounted.

Yeah, I'm also thinking about it, but your mainline goal will be reached sooner I guess. BTW: I think Armbian could have kswapd issue too if some memory heavy process is run.

If you want something useful, you should add udev rule: SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="sunxi-gpiokey", TAG+="power-switch" However, this will shutdown your board, because it sends KEY_POWER. I think kernel patch is needed if you want to change it to KEY_SLEEP. Waking from suspend should work flawlessy now on Armbian. I reorganized all patches in OpenELEC and kernel configuration so the kernels are more similar now. I still have CMA/kswapd issue, but I still have one idea what to change. In the process, I found the reason why suspend on OpenELEC doesn't work. It works when CMA is enabled Nice progress in unifying all the images. Did you consider porting MMC driver from mainline kernel to solve the issues?

I really don't remember now, I think I searched for some H3 source on net and took the newest I could find. Maybe even from orangepi forum. Maybe it's time to switch to another, probably it would be best if we have same codebase. At least your kernel don't show any problems which mine have. I'm a bit woried about mali driver. Which version of binary blob do you have? I'm using fbdev version... I saw that (I'm tracking IRC just not talking). Frankly speaking, I was very excited at first, but then I saw that all driver configuration is based on device tree. I'm not sure if there is any point putting so much work into porting that... Don't get me wrong, I would like to have better sound drivers among other things. EDIT: I think I'm using sources from h3-lichee-1.0.tar.gz

Currently I feel like Frankestein who's creating his own monster. Kernel includes so many backports and ports already that I'm surprised it's still working. Yeah, I concur that maintaining such a repo would be a nightmare. But maybe if there is a team of few people, it would be manageble... BTW: I took a quick look at Armbian and I'm surprised there is no kswapd issue. Did you do anything about that or there wasn't any from the beginning?

Hm... Issue went away by itself Interesting, OpenELEC has basically the same kernel, but it has severe issues at waking up from suspend. Any idea? My use case: go to sleep with "systemctl suspend" and then wake up with power button. Supporting different boards is no problem for me. As you said, different script.bin's, maybe module loading and boot.cmd. Currently I'm in a bad mood because I can't figure this suspend... What about having commong H3 linux repository? I know that there is not much interest because mainline H3 support is progressing nicely, but multimedia distribution like OpenELEC would benefit.

I can confirm that new script.bin solves reboot issue on OPi2. BTW: Did anyone look into suspend issue?

Did anyone noticed that pine64 source code includes newer version of Allwinner's U-Boot? It seems to me that at least some drivers could be reused. like NAND, arisc, video... If NAND driver works as expected, we could support booting from flash. Although their kernel source doesn't support H3 per se, it includes some drivers which should have some improvements against our code base. For example, I noticed that disp2 driver has quiet a lot of changes. Most of them are code reorganization, but some has actual meaning, like additional checks before doing stuff... EDIT: Does mainline U-Boot already supports NAND booting on H3?

I'm from Slovenia too, but we will have a meeting in Nuremberg. On topic: What do you say if I adapt 1-wire patch which would take standard GPIO settings, e.g.: [w1_para] w1_used = 1 gpio = port:PA20<1><default><default><0> It seems to me that it would be less confusing for users.

@tkaiser, I saw your talk on IRC about camera module. Be aware that "SATA fix" also enabled CSI port (well, one pin on it). It could be that this was (part of) the problem. I can't test it, because I don't have a camera module. I really don't know what to do about GPIO configuration. RPi is in advantage here because you don't need to set functionality at boot AFAIK. I'm very glad that mainline kernel is coming along

I made it myself. It's simple. Pin can be defined either as GPIO or something else, e.g. I2C, but not both at the same time. On orange pi forum was one idea, that at least one SPI and one I2C should be defined by default instead of GPIO. That's it. I also won't have much time for developing in following days, but I will be able to write some posts.

I hope you don't mind if I join your party My fbdev patch allows changing only to already supported resolutions on the fly, but you must be aware of two things: 1. video memory gets reserved at boot, so you can't change to resolution bigger than it was set at boot, 2. fbset changes only framebuffer resolution info, but doesn't actually switch to it in HW - that can be done via debugfs or disp2's ioctl interface debugfs method: sudo su cd /sys/kernel/debug/dispdbg/ echo "switch" > command echo "disp" > name echo "4 5" > param echo "1" > start where 4 means HDMI output and 5 has the same meaning as in script.bin. For ioctl variant, which is more C friendly, you can check my Kodi patch. Also one note on your unifying attempt and gmac patch / script.bin dilemma. Please check my github for updated patch. Idea behind it is that driver doesn't fail if there is no [gmac_phy_power] section in script.bin. That way you don't need to change script.bin at all. And last but not least, if you want to use sy8106a patch on u-boot, you must update u-boot to version 2016.03-rc2.