jernej

Not sure if this would help. On H3 U-Boot is actually responsible for bringing up all cores through PSCI interface.

I also get instant crash on my OpenELEC fork for opiplus2e. sheffield_nick, are you using desktop version of Armbian, e.g. with graphical interface? There are some fixes for A20 legacy kernel for 2GB memory, but they are all related to video and gpu driver. If you confirm this, it is worth looking into...

One user reports constant freezes for 1-2 seconds after every button press and that suspend/resume cycle works only first time. Tested on LG TV if that helps anything.

Before hciattach run this: echo " " > /dev/ttyS1 This will correctly set RTS line, I believe and following hciattach won't fail anymore.

AFAIK, libvdapu-sunxi don't currently have a capability to use second screen. If it is similar enough to Kodi in OpenELEC, code could be fixed quiet easily. I will take a look at code.

CONFIG_TV_DISP2_SUNXI=m means that you have to modprobe tv driver first

That's the point. I will probably leave it as is. A lot will change anyway and I can't switch so quickly, because a lot of drivers still missing.

systemd service works, for example: [Unit] Description=h3 suspend service Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=-/bin/sh -c "echo 1 > /sys/class/leds/green_led/brightness; echo 1 > /sys/class/leds/red_led/brightness" ExecStop=-/bin/sh -c "echo 0 > /sys/class/leds/green_led/brightness; echo 0 > /sys/class/leds/red_led/brightness" [Install] WantedBy=sleep.target ExecStart will execute at suspend and ExecStop will execute at resume. Please note that above example is taken from OpenELEC, which has slightly different LED settings, but principle is the same.

I'm using DHCP to my computer and serial console (which is a must for debugging sleep issues). Maybe this will help you with setting static ip.

Thanks for looking into issues. Power off in Kodi is actually suspend, not a proper shutdown. Otherwise it wouldn't be possible to wake it up. You can debug this issues with appending "no_console_suspend" in U-Boot kernel parameters and executing "echo 8 > /proc/sys/kernel/printk" in console. I think that at least some messages will be useful to you. There is also another bug at suspend. If you have USB hub connected to any port and that hub has some USB device connected to it, it will crash at suspending (watchdog timer). I tried to debug this issue, but I couldn't find what is wrong. You can do a proper shutdown from console with standard "shutdown now" commnad. Don't mind screensaver issue. It might be because of buffer overflow you mentioned or some other thing. If it will still exist after your bugfix, I will check the code what is happening in that moment.

This is known. Set module parameter for that. You can use same way as Igor did for 3.4.

Great to hear! Is driver autoloaded or not?

It's hard to trace through Allwinner's code, but do you know by any chance why suspend and resume wouldn't work? It seems to me that you already have notification for that, but I'm not sure. One user reports that CEC diagnostic would often crash OPi Plus board. Any thoughts on that? I really don't know how diagnostic looks like... EDIT: It seems that hdmi suspend function is not called anywhere. EDIT2: Or it is... Can you just check that suspending turns tv off?

Can you post full dmesg?

You're welcome. I'm really interested what's left to be fixed... /offtopic Do you know anything about the state of his display engine driver?

Last time I tested this was with 4.6.0-rc1 on OPi2. You can take a look also here: http://moinejf.free.fr/opi2/8189es.patchMost interesting part would be platform file...

All seems good. How does your system behave? When I start board, I didn't even need to modprobe, because sdio interface has similar autoloading mechanism to USB. Maybe you can check if kernel even detected your wifi chip. This can be done over /sys interface, I'm just not sure how exactly. Maybe you can measure power pin with multimeter. Another attempt would be setting pin in u-boot just to be sure it's on...

First report: http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect&goto=findpost&ptid=648&pid=13713&fromuid=198504 Thank you very much! Do you see room for improvement or that's it?

You didn't forgot to add pin configuration like here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts?id=refs/tags/v4.7-rc3#n160(line 160)? Can you show your dts?

Ok, I checked few things and this should work: 1. edit platform/platform_ops.c and remove lines from 34 to 39 so the function will just return 0. 2. deselect all platforms in Makefile 3. compile with: make KSRC=/lib/modules/$(uname -r)/build ARCH=arm

Why don't you just disable all platforms and when you get compile error, check how it was fixed in RTL8189ES sources. HAL part should be very similar.

Ah, sorry. I spoke to quickly. Actually, you shouldn't set any platform. Check this: https://github.com/jwrdegoede/rtl8189ES_linux/blob/master/MakefileAnyway, you don't need to do anything for sdio. Just be sure that you have enabled power this way: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts?id=refs/tags/v4.7-rc3#n98

You should mark it as 386 platform, e.g. no special platform initialization. Also copy wifi power part from OPi2 dts.

C.H.I.P. is Next Things SBC based on Allwinner R8 chip (similar to A13, I think) https://getchip.com/ Quoted from github: I'm not a gamer, but OpenGL 1.x sounds like that you won't be able to play many games.

Just my 2 cents: Mali drivers in current form are not useful on mainline, but mripard ported kernel part for C.H.I.P. (R8) already, so if there is interest, it can be done. But first you need video driver to actually output any image to display, which is work in progress. Anyway, GL ES wouldn't help you in normal usage, except for games and Kodi, as tkaiser already said.