Build: Improving sun8i dev?

[ThomasKaiser]

I would suggest switching sun8i-dev to branch orange-pi-4.9-hdmi since it boots. Beelink X2 running from SD card first and then eMMC later: http://sprunge.us/VjJP

Then it would be great to patch the 2nd led and &ohci3/&ehci3 into sun8i-h3-bananapi-m2-plus.dts (so choosing BPi M2+ target will produce a nearly perfect OS image for OPi Plus 2E too)

And IMO it would be worth a try to enable CONFIG_F2FS_FS_ENCRYPTION=y and encourage users to try with encrypted rootfs (just kidding, I was making jokes about the amount of feedback on this)

[zador-blood-stained]

I would suggest switching sun8i-dev to branch orange-pi-4.9-hdmi since it boots.

Some developers delete feature branches after they are merged into current/master, so maybe use orange-pi-4.9 for now?

[ThomasKaiser]

I'm fine with both, just thought maybe we get also some feedback on HDMI/Audio issues and are able to switch from orange-pi-4.9-hdmi to orange-pi-4.9 as soon as the former disappears?

BTW: I only tested with orange-pi-4.9-hdmi shortly and there /sys/devices/system/cpu/cpu0/cpufreq is gone (no idea whether the location changed or there's a DT problem -- I had this once with Cubietruck where cpufreq support was missing due to dvfs problems in DT)

[ThomasKaiser]

Cpufreq scaling is definitely broken with my 4.9 based image: sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4 takes ~346 seconds which translates to ~500 MHz cpufreq on average (reported SoC temperature 6°C above idle)

Don't have the time to do further testing this week :(

[ThomasKaiser]

Gna... just looked through dmesg output and maybe already found the culprit:

sy8106a 0-0065: Failed to read voltage at probe time: -6

This is Beelink X2 which uses settings for Orange Pi PC Plus. So for Beelink X2 to be used with dev branch the ugly work-around would be to set BOOTCONFIG=FriendlyARM_NanoPi_Air_defconfig and a better way would be to add the following to add-missing-h3-boards.patch:

diff --git a/configs/Beelink_X2_defconfig b/configs/Beelink_X2_defconfig
new file mode 100644
index 0000000..5ba9f9e
--- /dev/null
+++ b/configs/Beelink_X2_defconfig
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=624
+CONFIG_DRAM_ZQ=3881979
+CONFIG_DRAM_ODT_EN=y
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-orangepi-one"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2

But since Beelink X2 owners don't seem to be keen on trying out mainline kernel we can postpone the whole thing. BTW: Same 'problem' should apply to Banana Pi M2+ too since Sinovoip_BPI_M2_plus_defconfig is also using CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-orangepi-pc" which should read CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-bananapi-m2-plus" now with megi's 4.9 branch.

[zador-blood-stained]

@ThomasKaiser
What boards did you test with 4.9 branch? I've got udev+kernel crash with OpiPC. I think I had something similar on 4.8 branch too.

[ThomasKaiser]

What boards did you test with 4.9 branch?

Only Beelink X2 and I've to admit that my successful tests were with Armbian's sun8i-dev default .config from 4.8.

After going through KERNEL_CONFIGURE="yes" I experienced strange behaviour (freezes but also Beelink X2 booting from eMMC with SD card inserted and throwing errors about mmc all the time) but gave up since it was already pretty late.

In other words: I can only confirm that 4.9 kernel ran on Beelink X2 when using default sun8i-dev config for 4.8.

BTW: After recent forum comments I will now slow down a lot. No useful community feedback/help and our try to constantly improve things don't match.

[zador-blood-stained]

In other words: I can only confirm that 4.9 kernel ran on Beelink X2 when using default sun8i-dev config for 4.8.

I didn't touch kernel config yet, will try to test smaller Orange boards later.

BTW: After recent forum comments I will now slow down a lot. No useful community feedback/help and our try to constantly improve things don't match.

I agree about lack of help or feedback, but regarding forum posts, comments or questions, the simplest solution is ignoring the worst cases and focusing on constructive discussions and on topics where people know what they are doing.

[ThomasKaiser]

regarding forum posts, comments or questions, the simplest solution is ignoring the worst cases

You're absolutely right but unfortunately I'm not that good in that area. I know why I try to support Armbian project and doing unpaid 1st level support wasn't one of the goals. But anyway...

I thought about situation with 4.9 on X2 again and maybe most simple test case is to let cpufreq scaling fail? Since this was the other change (sorry, forgot to report before): I switched to BOOTCONFIG=Beelink_X2_defconfig and added aforementioned stuff to add-missing-h3-boards.patch.

[igorpecovnik]

If 4.8 is broken I see no problem switching to 4.9. I haven't test any but better to have one bootable image than none. I added OPi PC to auto building. In general we probably need to slow down the testing cycle to get better / results at all.

[igorpecovnik]

4.9 from this morning also hangs here: (OPi PC+)

[   30.221117] INFO: rcu_sched detected stalls on CPUs/tasks:
[   30.226638]  1-...: (1 GPs behind) idle=127/140000000000000/0 softirq=761/791 fqs=561 
[   30.234551]  3-...: (0 ticks this GP) idle=c9d/140000000000000/0 softirq=1223/1223 fqs=561 
[   30.242889]  (detected by 2, t=2102 jiffies, g=-96, c=-97, q=25373)
[   93.271114] INFO: rcu_sched detected stalls on CPUs/tasks:
[   93.276632]  1-...: (1 GPs behind) idle=127/140000000000000/0 softirq=761/791 fqs=3713 
[   93.284632]  3-...: (0 ticks this GP) idle=c9d/140000000000000/0 softirq=1223/1223 fqs=3713 
[   93.293057]  (detected by 0, t=8409 jiffies, g=-96, c=-97, q=25901)
[  156.321112] INFO: rcu_sched detected stalls on CPUs/tasks:
[  156.326613]  1-...: (1 GPs behind) idle=127/140000000000000/0 softirq=761/791 fqs=6865 
[  156.334609]  3-...: (0 ticks this GP) idle=c9d/140000000000000/0 softirq=1223/1223 fqs=6865 
[  156.343035]  (detected by 0, t=14714 jiffies, g=-96, c=-97, q=25902)

[WereCatf]

I just tried 4.9.0 on OPi PC and it seems to actually work pretty well -- ethernet works well, the board seems stable and all. No framebuffer and no frequency-scaling, but I assume those aren't even supposed to be working yet?

I did notice that the entry for enabling/disabling i2c2 in DTB is wrong, it tries to use the same regs as i2c1. I dunno if it matters, but I submitted a pull-request for that.

[ThomasKaiser]

No framebuffer and no frequency-scaling, but I assume those aren't even supposed to be working yet?

Could've been working both. We switched to @megous's repo with ths/dvfs/cpufreq stuff working months ago, it worked fine with 4.6 and 4.7, it stopped to work with 4.8.

I then simply tried out https://github.com/megous/linux/tree/orange-pi-4.9-hdmi and it seemed to work for me but only since my settings for Beelink X2 were 'wrong' anyway and the ths code failed (using Orange Pi PC DT and expecting SY8106A voltage regulator which is not present on Beelink X2). As soon as I used correct settings I also experienced kernel freezes.

When we started with megi's settings half a year ago this u-boot patch was needed to get THS stuff working (I asked megi back then about that). Now it seems no one asked (maybe it's just another mini u-boot patch?) and we switched the repo to montjoie's where THS stuff isn't integrated.

[WereCatf]

One thing I did notice about Ethernet is that I can only get about 600KBps-700KBps out of it. It's fine for SSH-console, but not quite useful for much else 😄

[niaow]

I just tried this on my Orange Pi One. It hangs at "Starting Flush Journ`l to Persistent Storagd..." (sorry, my makeshift serial adapter is really bad) with btrfs.

[niaow]

May or may not be related: https://github.com/systemd/systemd/issues/2994

[ThomasKaiser]

Don't have the time to dig deeper, so just a few notes. Problem with sun8i dev seems to be solvable according to megi: http://www.cnx-software.com/2016/11/10/allwinner-h2-linux-android-sdk-and-allwinner-xr819-wifi-driver-released/#comment-535557

Then I had to disable sun8i-dev/add-olinuxino-a33.patch to get sun8i dev kernel to compile (why is the patch there at all? I thought the A33 should be handled by next branch?).

When using dev branch there's still a warning of this kind package linux-libc-dev-dev-sun8i in control file but not in files list (noticed this already back in April but forgot about it)

And I could reproduce both the warning regarding sshd_config and lirc/hardware.conf from here.

dpkg-deb: building package 'linux-firmware-image-dev-sun8i' in '../linux-firmware-image-dev-sun8i_5.24_armhf.deb'.
dpkg-deb: building package 'linux-dtb-dev-sun8i' in '../linux-dtb-dev-sun8i_5.24_armhf.deb'.
dpkg-deb: building package 'linux-headers-dev-sun8i' in '../linux-headers-dev-sun8i_5.24_armhf.deb'.
dpkg-deb: building package 'linux-image-dev-sun8i' in '../linux-image-dev-sun8i_5.24_armhf.deb'.
dpkg-genchanges: warning: package linux-libc-dev-dev-sun8i in control file but not in files list
dpkg-genchanges: binary-only upload (no source code included)
[ o.k. ] Creating board support package [ orangepizero dev ]
[ .... ] Fingerprinting 
[ o.k. ] Building package [ linux-xenial-root-dev-orangepizero ]
[ o.k. ] Starting rootfs and image building process for [ orangepizero xenial ]
[ o.k. ] Extracting xenial-ng-armhf.d7d...20a.tgz [ 0 days old ]
xenial-ng-armhf.d7d...20a.tgz: 88,4MiB [11,2MiB/s] [===================================================================================================>] 100%
[ o.k. ] Applying distribution specific tweaks for [ xenial ]
sed: can't read /var/syslog-ng/Armbian/output/cache/sdcard/etc/ssh/sshd_config: No such file or directory
[ o.k. ] Applying common tweaks 
[ o.k. ] Installing kernel [ linux-image-dev-sun8i ]
[ o.k. ] Installing u-boot [ linux-u-boot-dev-orangepizero ]
[ o.k. ] Installing headers [ linux-headers-dev-sun8i ]
[ o.k. ] Installing generic firmware [ armbian-firmware ]
[ o.k. ] Installing DTB [ linux-dtb-dev-sun8i ]
[ o.k. ] Installing board support package [ orangepizero ]
sed: can't read /var/syslog-ng/Armbian/output/cache/sdcard/etc/lirc/hardware.conf: No such file or directory
sed: can't read /var/syslog-ng/Armbian/output/cache/sdcard/etc/lirc/hardware.conf: No such file or directory
sed: can't read /var/syslog-ng/Armbian/output/cache/sdcard/etc/lirc/hardware.conf: No such file or directory
cp: cannot create regular file '/var/syslog-ng/Armbian/output/cache/sdcard/etc/lirc/lircd.conf': No such file or directory
Hit:1 http://ports.ubuntu.com xenial InRelease
Hit:2 http://apt.armbian.com xenial InRelease
Hit:3 http://ports.ubuntu.com xenial-security InRelease
Hit:4 http://ports.ubuntu.com xenial-updates InRelease
Hit:5 http://ports.ubuntu.com xenial-backports InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libnl-3-200 libnl-genl-3-200 libusb-1.0-0
Recommended packages:
  u-boot-sunxi:armhf
The following NEW packages will be installed:
  hostapd libnl-3-200 libnl-genl-3-200 libusb-1.0-0 sunxi-tools
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 425 kB of archives.
After this operation, 949 kB of additional disk space will be used.
Get:1 http://apt.armbian.com xenial/utils armhf hostapd armhf 1:2.5~armbian5.23+1 [305 kB]
Get:2 http://ports.ubuntu.com xenial/main armhf libusb-1.0-0 armhf 2:1.0.20-1 [37.6 kB]
Get:3 http://ports.ubuntu.com xenial/main armhf libnl-3-200 armhf 3.2.27-1 [44.9 kB]
Get:4 http://ports.ubuntu.com xenial/main armhf libnl-genl-3-200 armhf 3.2.27-1 [9522 B]
Get:5 http://ports.ubuntu.com xenial/universe armhf sunxi-tools armhf 1.3-1 [27.3 kB]
Fetched 425 kB in 0s (1529 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = "en_US:en",
    LC_ALL = (unset),
    LANG = "de_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
Selecting previously unselected package libusb-1.0-0:armhf.
(Reading database ... 33234 files and directories currently installed.)
Preparing to unpack .../libusb-1.0-0_2%3a1.0.20-1_armhf.deb ...
Unpacking libusb-1.0-0:armhf (2:1.0.20-1) ...
Selecting previously unselected package libnl-3-200:armhf.
Preparing to unpack .../libnl-3-200_3.2.27-1_armhf.deb ...
Unpacking libnl-3-200:armhf (3.2.27-1) ...
Selecting previously unselected package libnl-genl-3-200:armhf.
Preparing to unpack .../libnl-genl-3-200_3.2.27-1_armhf.deb ...
Unpacking libnl-genl-3-200:armhf (3.2.27-1) ...
Selecting previously unselected package hostapd.
Preparing to unpack .../hostapd_1%3a2.5~armbian5.23+1_armhf.deb ...
Unpacking hostapd (1:2.5~armbian5.23+1) ...
Selecting previously unselected package sunxi-tools.
Preparing to unpack .../sunxi-tools_1.3-1_armhf.deb ...
Unpacking sunxi-tools (1.3-1) ...
Processing triggers for libc-bin (2.23-0ubuntu4) ...
Processing triggers for systemd (229-4ubuntu12) ...
Processing triggers for ureadahead (0.100.0-19) ...
Setting up libusb-1.0-0:armhf (2:1.0.20-1) ...
Setting up libnl-3-200:armhf (3.2.27-1) ...
Setting up libnl-genl-3-200:armhf (3.2.27-1) ...
Setting up hostapd (1:2.5~armbian5.23+1) ...
Running in chroot, ignoring request.
invoke-rc.d: policy-rc.d denied execution of start.
Setting up sunxi-tools (1.3-1) ...
Processing triggers for libc-bin (2.23-0ubuntu4) ...
Processing triggers for systemd (229-4ubuntu12) ...
Processing triggers for ureadahead (0.100.0-19) ...
[ o.k. ] Calling image customization script [ customize-image.sh ]
[ o.k. ] Preparing image file for rootfs [ orangepizero xenial ]
[ o.k. ] Current rootfs size [ 415 MiB ]
[ o.k. ] Creating blank image for rootfs [ 710 MiB ]
 710MiB [  80MiB/s] [==================================================================================================================================>] 100%
[ o.k. ] Creating partitions [ root: ext4 ]
[ .... ] Creating rootfs [ ext4 ]
[ o.k. ] Copying files to image [ tmprootfs.raw ]
        342.67M  98%   17.22MB/s    0:00:18 (xfr#27909, to-chk=0/35230)   

sent 344.68M bytes  received 563.08K bytes  17.70M bytes/sec
total size is 347.20M  speedup is 1.01
[ o.k. ] Copying files to /boot partition [ tmprootfs.raw ]
         17.99M  99%  112.66MB/s    0:00:00 (xfr#151, to-chk=0/157) 

sent 18.00M bytes  received 2.91K bytes  36.01M bytes/sec
total size is 17.99M  speedup is 1.00
[ o.k. ] Free space: [ SD card ]
/dev/loop0p1                  682M  430M  224M  66% /var/syslog-ng/Armbian/output/cache/mount
[ o.k. ] Writing U-boot bootloader [ /dev/loop0 ]
[ o.k. ] Done building [ /var/syslog-ng/Armbian/output/images/Armbian_5.24_Orangepizero_Ubuntu_xenial_4.7.10.img ]
[ o.k. ] Runtime [ 9 min ]

[zador-blood-stained]

And I could reproduce both the warning regarding sshd_config and lirc/hardware.conf from here.

For me this is the most interesting part since this means that one of debootstrap stages failed but failure was not detected by exit code. Can you please try to reproduce it again with PROGRESS_LOG_TO_FILE=yes after clearing rootfs cache? I'm mostly interested in packages installation part, since 80MB for rootfs is too low.

[zador-blood-stained]

Don't have the time to dig deeper, so just a few notes. Problem with sun8i dev seems to be solvable according to megi

If I remember correctly I did enable sunxi-ng during my tests.

Then I had to disable sun8i-dev/add-olinuxino-a33.patch to get sun8i dev kernel to compile (why is the patch there at all? I thought the A33 should be handled by next branch?).

@igorpecovnik should know why this is here.

When using dev branch there's still a warning of this kind package linux-libc-dev-dev-sun8i in control file but not in files list (noticed this already back in April but forgot about it)

I think this can be ignored.

[igorpecovnik]

a33 olimex can be removed / ignored from DEV.

[ThomasKaiser]

Can you please try to reproduce it again with PROGRESS_LOG_TO_FILE=yes after clearing rootfs cache?

Is this already sufficient? IIRC I cleared rootfs cache directly before. If it takes too much time for you to look into just drop me a note and I retry.

[ThomasKaiser]

Megi's branch is reported to work _now_ again: https://github.com/megous/linux/commits/orange-pi-4.9

In linux-sunxi irclog experiences are exchanged and also patches flying around to support the stuff on the larger Oranges (dvfs operating points not looking good to me though)

[WereCatf]

Oh, that's nice. Imma give it a whirl later on today and see how many things I can break this time around :D It's starting to look like mainline may soon be reasonably-useable, even if sound is missing, and such a notion pleases me greatly.

[ThomasKaiser]

@WereCatf please be aware that while it seems that's now stable it seems thermal readouts are way too low. I did some tests a while ago (with 4.7 IIRC) and back then I noticed no differences between SoC temperatures reported with legacy and mainline kernel (tested exactly that for a reason -- since I never trust in numbers spitten out by a driver trying to interpret a sensor again :) ).

It's known that with legacy kernel temperature readouts from SoC differ by 10°-15°C when switching between Allwinner's legacy u-boot (2009.11) and mainline. I talked about that with @ssvb back then and he thought that it might be related to clocks somehow.

Since now people report way too low temperatures and megi changed something with clocks in latest commits this sounds now even more reasonable. Maybe someone finds out.

[martinayotte]

For particular case of PineA64, I think we should stay on Icehowy's branch until her USB stuff get merged into Mainline.

[ThomasKaiser]

@martinayotte Agree for Pine64 but would also propose to switch back to megi's 4.9 branch for H3 ASAP. Jonkerj's last 3 commits (should) add even more features and maybe we get more useful feedback on both thermal/throttling issues and USB OTG (might require switching on some gadget stuff in kernel config) than now.

Will test that myself later, currently at a customer with no access to build system.

[martinayotte]

In this case, maybe in the mean time, we can extract Icehowy USB as a patch and try it out on Megous branch.

[WereCatf]

3D-acceleration with mainline-kernel should be feasible with mali r6p0, if only I knew what to put in the device-tree... ☹️

[ThomasKaiser]

@WereCatf I only know that @Icenowy reported being successful with 4.9 and A33 (same Mali inside) here. But I would believe that it gets slightly off-topic here and the best place to reach her is linux-sunxi IRC

Another off-topic remark asking for your help/intervention: Do you think we're currently trying to re-invent the wheel with this (I tried to start something in an area I'm not that familiar with -- same mistake again and again)?

[WereCatf]

Personally, I think the whole WiringPi-thing is crude and awful. It was designed for and only Raspberry Pis, and as such all the references to BCM-pin numbers and RPi-headers and such don't make any sense. A more generic library that can take into account the fact that some boards may not have a full RPi-compatible 40-pin header or may have multiple headers, and one that doesn't reference Broadcom and/or RPi when it's not applicable would be a much more preferable approach, IMHO. Even extending libsoc to be able to address pins via mmap would be preferable over yet-another WiringPi-wannabe.

[zador-blood-stained]

As expected, orange-pi-4.9-hdmi branch was removed and orange-pi-4.9 now contains HDMI driver.
Looks like DE2 driver crashes on shutdown (at least when compiled as module), but other than that (and some random crash on startup probably related to crappy SD card) this kernel works fine enough on OPi One.

[WereCatf]

It worked well-enough on the OPi PC, too. At this rate mainline will actually be useable soon.

[ThomasKaiser]

Tested it also on OPi Plus 2E (though with 'OPi Plus' DT -- still too lazy to figure DT differences out, maybe @vincele had a look already?). IMO we should switch to this branch rather sooner than later.

[vincent-legoll]

I've not dug into DT differences yet, but the megous branch is booting / working (eth & wifi) on opi+2e with bpim2+ DT. No HDMI output on my crappy TV (may not be driver's fault, that's hard to tell).

What other things should be tested / reported ?
Is there a checklist (wiki ?) of valuable things to do ?
W/ maybe per board sections...

[ThomasKaiser]

If OPi Plus 2E is working with BPi M2+ DT then it's just patching in ehci3, ohci3 and the missing led (similar to OPi One DT currently). Looks like an easy task but on the other hand providing end user images with dev kernel seems to be useless (to get feedback and bridge the gap between kernel devs and users)

Write "A is broken but we need feedback on B, please test 4.9 dev images here!" and people start immediately to run Docker instances on H3 boards mentioning B would not be worth a look, A would be broken and ask when the 'Armbian fix' is ready ;)

I fear most of the feedback should be sent/discussed upstream (linux-sunxi ML and IRC)

[ThomasKaiser]

Just a random thought: Since xradio driver for 4.9 seems to work better than the original one for legacy kernel what about dropping legacy support for this board entirely?

All that's missing is adding @fifteenhex's cleaned up driver and DT bits to get WiFi working (thought already about that but since I damaged my board WiFi isn't working any more here so I can't test) and missing 2D/3D/video acceleration shouldn't be an issue. Well, while I do believe there are people out there buying an Orange Pi Zero instead of an OPi One to save $3 and to mis-use it as a desktop replacement with an old TV I think not supporting such scenarios from the very beginning could help dealing with this kind of users.

Of course h3consumption tool won't work with mainline kernel but to be honest the only really interesting setting regarding low idle consumption is adjusting DRAM clockspeed and we already use a pretty sane value here so there's not that much to optimize anyway. And consumption with mainline kernel and identical settings has always been lower compared to legacy.

[Icenowy]

2016年12月5日 06:12于 Thomas Kaiser [e-mail]写道：
>

Just a random thought: Since xradio driver for 4.9 seems to work better than the original one for legacy driver what about dropping legacy support for this board entirely?

Excuse me... As the first porter of xradio, how can it run better on mainline ;-)

Maybe it's just because mainline is more stable ;-)

But I do admit mainline is better for opi0; However the "official" tree hasn't still merged the opi0 support patch (also sent by me).

>

All that's missing is assembling these few bits to get WiFi working (thought already about that but since I damaged my board WiFi isn't working any more here so I can't test) and missing 2D/3D/video acceleration shouldn't be an issue. Well, while I do believe there are people out there buying an Orange Pi Zero instead of an OPi One to save $3 and to mis-use it as a desktop replacement with an old TV I think not supporting such scenarios from the very beginning could help dealing with this kind of users.

I agree with it. Opi0 is designed as a headless board.

The TV Composite output is even not enough for get a stable console for a server...

(P.S. In order to test my new USB TV Stick, I tried to play a NES emluator on my CHIP with TV Composite video connect, which gives me really the game experience in the age of NES :-) Unstable image, difficult-to-read terminal, etc.

>

Of course h3consumption tool won't work with mainline kernel but to be honest the only really interesting setting regarding low idle consumption is adjusting DRAM clockspeed and we already use a pretty sane value here so there's not that much to optimize anyway. And consumption with mainline kernel and identical settings has always been lower compared to legacy.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[zador-blood-stained]

Just a random thought: Since xradio driver for 4.9 seems to work better than the original one for legacy kernel what about dropping legacy support for this board entirely?

Agree, but this can be done after main bits are merged to mainline, since right now all we have is a branch that sometimes randomly crashes on random boards and that has a potential of breaking (temporarily) in the future.

But Opi Zero, NanoPi Neo and similar headless boards can be the first Allwinner boards where legacy kernel will be obsolete.

[miltador]

I can confirm Orange Pi One booting and working with 4.9 kernel. However I noticed that only one core is shown in htop and /proc/cpuinfo. Is there only one core supported at the moment?

[WereCatf]

I tested mainline HDMI with another display today and for some reason it insists on setting a display-resolution of 1920x1080@56. I have no idea why it insists on such a weird refresh-rate. Heck, the display is 1280x800, so I don't know why it insists on setting 1920x1080, either.

The HDMI-driver is a mess :S

[Icenowy]

2016年12月10日 05:22于 WereCatf [e-mail]写道：
>

I tested mainline HDMI with another display today and for some reason it insists on setting a display-resolution of 1920x1080@56. I have no idea why it insists on such a weird refresh-rate. Heck, the display is 1280x800, so I don't know why it insists on setting 1920x1080, either.

The HDMI-driver is a mess :S

As I know, it do not support EDID well...

>

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[WereCatf]

@Icenowy Looks like it. But it's also completely ignoring kernel boot-arguments, too, it seems.

Oh well.. I just thought to test with a different display with a more standard resolution. 1280x800 60Hz should be a standard DMT HDMI-resolution.

[zador-blood-stained]

@WereCatf
Are you sure you tested DRM HDMI driver and not u-boot+simplefb one?

[WereCatf]

Yeah, I just had a typo that I failed to notice. It's not ignoring the arguments when typed in correctly! I still can't get the display to work with video=HDMI-A-1:1280x800@60 or any variations on that, or 1280x720. The kernel always sets some rather random refresh-rate and ends up using an unsupported one and then the display ain't working.

[Icenowy]

2016年12月10日 17:03于 Mikhail [e-mail]写道：
>

@WereCatf
Are you sure you tested DRM HDMI driver and not u-boot+simplefb one?

The U-Boot+SimpleFB one is more suitable.

I'm using it on my HDMI LCD which supports only one mode 1024x600@60Hz.

Neither the BSP driver nor the DRM driver works on this screen.

>

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[jernejsk]

I know I'm bit late, but just for clarification:
Current DRM driver support only resolutions supported by BSP driver.
I made U-Boot driver for proof of concept that it is possible to support other resolutions just as well.

[zador-blood-stained]

Well, I guess after the main DRM related stuff is implemented and merged, it would be relatively easy to add custom resoultions support. For now I believe there are enough problems to solve for the initial mainlining effort.

[jernejsk]

I'm pretty sure mripard won't allow to merge HDMI drivers until it uses already present driver in mainline (dw_hdmi). At that point it would be weird if driver wouldn't support custom resolutions. So I guess it will take some time until this happens. For now, we are waiting that improvements made for Renesas are merged into drm-next. After that, it will be relatively easy to add HDMI driver support for H3 and newer chips.

[Icenowy]

2017年1月6日 18:56于 Jernej Škrabec [e-mail]写道：
>

I'm pretty sure mripard won't allow to merge HDMI drivers until it uses already present driver in mainline (dw_hdmi). At that point it would be weird if driver wouldn't support custom resolutions. So I guess it will take some time until this happens. For now, we are waiting that improvements made for Renesas are merged into drm-next. After that, it will be relatively easy to add HDMI driver support for H3 and newer chips.

I think we can first get DE2 support merged, as we have now SoC with LCD support -- A64 and V3s.

P.S. moinejf seems to have things about allwinner removed on his homepage...

>

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[jernejsk]

Are you interested enough to figure out LCD on V3s or A64?

[Icenowy]

2017年1月6日 下午7:05于 Jernej Škrabec [e-mail]写道：
>

Are you interested enough to figure out LCD on V3s or A64?

Of course, and I have both :-)

but for A64, I have only Pine64, which have only MIPI DSI screen port, and the DSI part is a dedicated bridge.

>

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[ThomasKaiser]

moinejf seems to have things about allwinner removed on his homepage...

Yes. And the latest snapshot on web.archive.org is rather outdated :(

[zador-blood-stained]

I updated the sunxi-dev kernel branch to 4.10.
Some notes:

• additional USB ports for smaller boards (OPi One and Lite) are not enabled by default, instead we now have the DT overlays for it. Additional available USB port on Lite and ports on other boards that use Opi One DTS may be affected by this change - this needs to be tested

• analog audio output is enabled on OPi PC, OPi 2 and board that use their DT as a base. If there are other boards with 3.5mm jack - audio should be explicitly enabled there too, and for other boards we now have the DT overlay

• boards like NanoPi M1 and Banana Pi M2+ lack most of the additional DT patches

[ThomasKaiser]

@zador-blood-stained what do you think about creating a new pinned thread in H2/H3 forum (locked by default) explaining state of dev kernel on these boards and linking to this Github issue? We totally failed to get any _useful_ feedback from users running mainline kernel images and maybe with this move we encourage only those people to give feedback that have at least a Github account?

(Sorry, can't do that myself now since busy with preparing food -- also the next days on vacation here)

[zador-blood-stained]

what do you think about creating a new pinned thread in H2/H3 forum (locked by default) explaining state of dev kernel on these boards and linking to this Github issue?

I think that we already have too many forum posts with outdated info (but that can be found via a search engine), and explaining that "dev kernel is a dev kernel" yet another time won't change anything.

We totally failed to get any useful feedback from users running mainline kernel images and maybe with this move we encourage only those people to give feedback that have at least a Github account?

We got and still getting some feedback, and my post in this thread just marks a place where people who follow this repository for mainline H3 news can drop a note that something fell off during this change - USB ports, Ethernet, wireless, etc.

[itdaniher]

I've validated USB ports, Ethernet, WiFi on the OPZ, kernel 4.9.4.

Slight performance regression (~10%, 84.5Mb/s vs 95.5Mb/s on legacy) on Ethernet via iperf.

cpufreq-info on 4.9.4 doesn't list frequencies above 1.01GHz, but this is probably just conservative settings for default use until DVFS improves in Mainline.

Looking forward to "mainline-jessie" builds for the OPZ, and (eventually) audio + spi support on mainline + h2.

Thanks all!

[zador-blood-stained]

Looking forward to "mainline-jessie" builds for the OPZ, and (eventually) audio + spi support on mainline + h2.

Analog audio and SPI are supported already, and as for the OS release - there will be Jessie stable builds, but for mainline based CLI/server images focus may shift to Debian Stretch once it is released.

[itdaniher]

Analog audio and SPI are supported already, and as for the OS release - there will be Jessie stable builds, but for mainline based CLI/server images focus may shift to Debian Stretch once it is released.

root@orangepizero:~# aplay -l
aplay: device_list:270: no soundcards found...

No spidev either but I haven't edited the device tree, so that doesn't surprise me.

I have great luck with Stretch, via dist-upgrade after flashing.

root@orangepizero:~# cat /etc/issue
Debian GNU/Linux 9 \n \l

Definitely happy to hear that switch in the works.

[zador-blood-stained]

aplay: device_list:270: no soundcards found...
No spidev either but I haven't edited the device tree, so that doesn't surprise me.

If you built full image with latest changes, try adding

overlays=spi1-spidev analog-codec

to /boot/armbianEnv.txt and rebooting.
SPI flash on SPI0 should be exposed as MTD partitions already, so using spi0-spidev won't work for SPI0

Edit: Note: Overlays will be renamed in the future to avoid conflicts between different SoCs.

[itdaniher]

SPI flash on SPI0 should be exposed as MTD partitions already,

Delightful! Didn't notice that.

If you built full image with latest changes

Just installed the kernel from apt. Running

 ii  linux-image-dev-sun8i              5.25                                 armhf        Linux kernel, version 4.9.4-sun8i

Assuming the changes you referred to didn't make it into 5.25, will have to try building from source.

Edit: tried your changes on my setup, arecord -l still reports no devices.

[itdaniher]

@miltador wrote:

I can confirm Orange Pi One booting and working with 4.9 kernel. However I noticed that only one core is shown in htop and /proc/cpuinfo. Is there only one core supported at the moment?

I'm seeing something similar on the OPZ running 4.9.4-sun8i from apt. /sys/devices/system/cpu shows cpu0..3 but there're no online files in those directories, just at /sys/devices/system/cpu/online

/sys/devices/system/cpu/offline lists 1-3

/proc/cpuinfo shows:

processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 24.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

I'm poking around the dtb for the opz as I can't figure out how to enable the other cores from sysfs.

[itdaniher]

The dtb looks normal... nothing obvious. Here's a relevant snip from dmesg.

[    0.002785] CPU: Testing write buffer coherency: ok
[    0.003341] CPU0: update cpu_capacity 1024
[    0.003354] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.003397] Setting up static identity map for 0x40100000 - 0x4010004c
[    0.007637] Brought up 1 CPUs
[    0.007654] SMP: Total of 1 processors activated (48.00 BogoMIPS).
[    0.007661] CPU: All CPU(s) started in SVC mode.

and edit: here's lscpu

Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0
Off-line CPU(s) list:  1-3
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Model:                 5
Model name:            ARMv7 Processor rev 5 (v7l)
CPU max MHz:           1008.0000
CPU min MHz:           120.0000
BogoMIPS:              100.80
Flags:                 half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

[zador-blood-stained]

I'm poking around the dtb for the opz as I can't figure out how to enable the other cores from sysfs.

Did you get the full dev image or only the kernel? CPU cores issue can happen ifyou are using wrong u-boot or wrong boot script (i.e. upgrading from legacy to mainline)

[itdaniher]

Started with 5.25 Jessie / Legacy, added linux-u-boot-orangepizero-dev, linux-image-dev-sun8i, linux-dtb-dev-sun8i replacing their non-dev equivalents. Pointers would be appreciated!

[zador-blood-stained]

Started with 5.25 Jessie / Legacy, added linux-u-boot-orangepizero-dev, linux-image-dev-sun8i, linux-dtb-dev-sun8i replacing their non-dev equivalents. Pointers would be appreciated!

Try starting with the latest dev nightly: https://dl.armbian.com/orangepizero/nightly/

Please note that additional USB ports will be disabled and will require DT overlays too

[itdaniher]

I'll give it a shot. Any chance we could see Jessie nightly builds for the opz? I know Debian 9 is right around the corner, but Debian 8 won't go out of style for awhile yet, and Ubuntu is scientifically proven to cause hives in 3/5 software engineers.[1]

[1] blatantly false (edit: see http://howfuckedismydistro.com/ubuntu/)

[zador-blood-stained]

Any chance we could see Jessie nightly builds for the opz?

We would rather add Debian Stretch nightlies (release already passed the full freeze point), and you can use this build script to make a Jessie image at any time if you want it.

[itdaniher]

I'd be delighted with Stretch nightlies.

I just flashed Armbian_5.25.170211_Orangepizero_Ubuntu_xenial_dev_4.10.0.7z nightly to an SD and tried to boot on an opz to no avail. Lights look OK but no DHCP lease handed out from my router. I get the same results if I manually try and install the relevant nightly kernel / u-boot packages on a working Debian install - no network, possibly no boot. (will verify after work when I get my UART cable out)

Trying Armbian_5.25.170209_Orangepizero_Ubuntu_xenial_dev_4.9.4.7z next...

[itdaniher]

Also @zador-blood-stained it may be slightly inefficient, but feel free to tag me if you ever need user feedback on a kernel build for the A20, H3, or H2. I already try and contribute a bit of cash each month to Armbian, but I'd be happy to help with testing however I can.

(edit: word choice)

[itdaniher]

edit: Armbian_5.25.170209_Orangepizero_Ubuntu_xenial_dev_4.9.4.7z seems to be working. It appears as if there was a regression between 02/11 and 02/09, resulting in an image that doesn't come up on network. As it's a nightly image, there's a non-zero chance something went wrong in the build, vs some breaking change introduced, although validating the 4.10 kernel on the H2+/H3 is something I'll do when another nightly is produced.

Putting in a good word for the 4.9.4 02/09 nightly

Verified 4.10.0 image:

gpg: assuming signed data in 'Armbian_5.25.170211_Orangepizero_Ubuntu_xenial_dev_4.10.0.img'
gpg: Signature made Fri 10 Feb 2017 12:56:14 AM PST
gpg:                using RSA key 93D6889F9F0E78D5
gpg: Good signature from "Igor Pecovnik (Ljubljana, Slovenia) <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF00 FAF1 C577 104B 50BF  1D00 93D6 889F 9F0E 78D5

[zador-blood-stained]

Hm. Ethernet looks broken on Zero, I'll try to investigate it later.

[itdaniher]

@zador-blood-stained Cool, assuming you reproduced an eth problem on zero with 4.10.0. I'll keep an eye for another testing image. Rgds!

[itdaniher]

Tested SPI and audio on 4.9.4 as per @zador-blood-stained's armbianEnv.txt edits suggested above:

root@orangepizero:~# uname -a
Linux orangepizero 4.9.4-sun8i #18 SMP Wed Feb 8 02:49:19 CET 2017 armv7l armv7l armv7l GNU/Linux
root@orangepizero:~# cat /boot/armbianEnv.txt
verbosity=7
console=both
disp_mode=1920x1080p60
rootdev=UUID=a6f35e92-8101-483b-8f63-aebfe0888b9d
rootfstype=ext4
overlays=spi1-spidev analog-codec
root@orangepizero:~# arecord -l
arecord: device_list:268: no soundcards found...
root@orangepizero:~# ls /dev/spide*
/dev/spidev32766.0

[zador-blood-stained]

Kernel 4.9.4 doesn't have audio support yet.

[zador-blood-stained]

I think this can be closed. sun8i-dev is at the point of merging to sunxi-next starting with 4.13, at least for basic CLI images.