[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

I adopted the settings and pressed cluelessly the power button a few times. Now I know that I would have to send the board to suspend before (or better not according to Jernej's last comments here)

 

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?

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

We started to use https://github.com/ssvb/linux-sunxi/tree/20151207-embedded-lima-memtester-h3as base and then I switched to Yann's h3-wip branch: https://github.com/O-Computers/linux-sunxi/commits/h3-wip -- on what is OpenELEC based? [...]

 

BTW: Since you mentioned the new A64 BSP. Simon put the list of changes online: http://paste.ubuntu.com/15174117/(sun8iw10/sun8iw11?! WTF?!). And I've to admit this looks really interesting from the H3 perspective.

 

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

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

Regarding a kernel repo. Good idea but we need someone who will maintain that. I would suspect H3 gets more popular the next time and then you'll have to deal with pull requests all the time. So out strategy is to collect moronically patches on top and wait until something breaks. And then start to think about a solution. If I understood Igor correctly he refrains from maintaining the kernel, same do I.

 

But I agree it would be useful, especially since the kernel base we're currently using is still missing a lot of the early contributions from Orange Pi forums (eg. camera support -- there were patches available in the OPi forums but they disappeared so now we would have to compare loboris' sources and ours to recreate a patch to get the camera module working)

 

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?

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

Which suspend issue?

 

BTW: If we succeed with such a 'one size fits it all' solution OpenELEC might benefit too. Be prepared that as soon as the Olimex H3 boards are out you get two new 'devices' as pull requests (that differ only regarding script.bin, maybe /etc/modules and maybe cpufreq settings)

 

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.

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

Would be helpful if users of the 2, 2 Mini, Plus or Plus 2 can try out the preliminary unified OS image that you also find there.

 

I can confirm that new script.bin solves reboot issue on OPi2.

 

BTW: Did anyone look into suspend issue?

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

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?

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

BTW: Do you guys (Igor and you) meet next week at Nuremberg or somewhere else (I ask since the only other guy called Jernej I know is from Slovenia -- one of the best times of my live being there working and constantly 'party hard')

 

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.

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

@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

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

Great, Igor already merged a pull request that's made totally of your stuff. Would also be great if someone else could look into your fallback for inappropriate script.bin settings (running out of time seriously)

 

I just wanted you to ask where the changes in script.bin regarding the GPIO pin definitions origin from? I thought the definition in loboris' script.bin would match already http://linux-sunxi.org/File:Xunlong_OrangePi_expansion_header_pinout.png

 

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

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.

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

I hope you don't mind if I join your party

 

There's still a bit to do. I'm already preparing h3disp (an utility that's only useful with 3.4.x since it will take script.bin and modify [hdmi_para] section to support different HDMI resolutions, patch the fex and convert back -- to be useable with Xunlong/loboris images too) but will first have a look into OpenELEC's/jernej's last patches that are display related since it would also be great to get fbset support to be able to use any display resolution possible.

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.